feat: let operators turn off database spans (#14552)

* feat: let operators turn off database spans

Database spans are the bulk of what gets exported. Measured against a live run with a
commercial APM on the other end: about 80% of exported spans were SQLAlchemy, roughly 50
spans per flow run against a single flow.execute. APMs bill per span ingested, so an
operator who turned export on to watch flow health pays mostly for connect and SELECT.

LANGFLOW_OTEL_DB_SPANS=false drops them. On by default, because the volume buys something:
in that same run 17% of pool checkouts took over 50ms and 4% took over 200ms, which is the
difference between knowing a run was slow and knowing it was slow waiting for the database.
Defaulting this off would hide the most common cause of a slow run behind a setting nobody
knows to look for.

Two gates. The instrumentor is not installed at all when it is off, so the spans are never
created rather than created and dropped, and the export scope set drops the scope as well,
which covers another library instrumenting sqlalchemy against our provider.

The setting can only ever subtract from the allowlist. That direction is the point: the
allowlist is what keeps prompt-carrying scopes out of the APM, so configuration must not be
able to widen it, and a test pins that across values including one naming an LLM scope.

Anything but a recognised false value leaves them on, so a typo cannot quietly stop
telemetry an operator believes is running. The doctor reports which way it is set, next to
the existing note about log bodies, since that is where an operator checks what they are
about to send.

* fix: report configuration state in the doctor, and prove instrumentation is skipped

Both from review.

The doctor said database spans "ARE exported". It only reads the setting, and cannot see
whether the instrumentor attached: _instrument_sqlalchemy swallows an ImportError or a
double-instrument call. So the line was a confident claim on exactly the box where it is
wrong. It now says export is enabled, and that the volume follows once instrumentation
attaches.

The disabled-path test only proved that no database spans were exported, which stays true
if the instrumentor attaches and the export filter drops its spans. That is not what the
setting promises: skipping instrumentation is what avoids paying span creation on every
query. Added a probe with a plain SimpleSpanProcessor and no filtering, so any span that
exists at all is visible, plus its positive control.

Verified rather than assumed: with _instrument_sqlalchemy forced to instrument regardless,
the new test is the only one of the 32 that fails.

No mock or spy, so the probe exercises the real instrumentor rather than asserting on a
call that was recorded.