Admin telemetry worker: trace transport, per-signal destinations and OTLP integration rework

[07prajwal2000]

Why

Closes the transport half of #195. A route could already be marked as traced and
the span data already existed, but nothing carried it anywhere: there was no
consumer, no way for a project to say where its telemetry should go, and no UI to
say it in.

What

Telemetry worker (deployments/telemetryWorker.ts) — drains FLUXIFY_TRACES
and exports each run to the project's own OTLP endpoint.

• Durable pull consumer on a Limits-retention stream: 7h max_age, 512 MiB,
  discard: old, so telemetry volume can never pressure artifact delivery (P1: artifact boot loads twice; every update rebuilds the whole route trie #191).
  Limits rather than Workqueue on purpose — a work queue permits one consumer
  per subject and the recording consumer (Execution recording: persist runs, list/detail endpoints and the portal viewer #208) is already planned.
• Acks and drops on a malformed payload or a missing destination instead of
  naking. Those fail identically on every redelivery, and unlike an uncompiled
  route, a lost trace is not a broken product.
• One tracer/meter provider per destination, LRU-capped and shut down on eviction,
  so a many-project instance does not leak socket pools.
• Admin-plane with database access, so OTLP credentials never enter an execution
  process.

Per-signal destinations — three project_settings keys rather than a new
column. project_settings already is the key/value store, and
settings.ai.loggerConnectionId was always the project's log destination, merely
misfiled under settings.ai.*; it stays readable as the logs fallback. Separate
keys per signal because a project with a traces backend and no metrics backend is
normal.

Integration rework — "Open Telemetry Logs" becomes "Open Telemetry": one
OTLP endpoint carries all three signals and the old name described only the first.
Stored rows are normalized on read, so no data migration. The alias is
deliberately not in the variant enum — that enum renders the dropdown, and an
alias there would offer the same thing twice.

Custom headers on both OTEL and Loki, cfg:-resolved like any other credential,
for ingestors keyed on an api key or tenant id instead of basic auth. User headers
are spread first so they cannot clobber Authorization or stream-name, and a
reference that resolves to nothing is dropped rather than sent empty — an empty
api key reads at the far end as a wrong credential, which is much harder to debug
than an absent one.

Portal UI — three integration pickers on project settings, each filtered by its
tag, so Loki never appears under traces or metrics. Test connection passes the
signal through.

Also drops the jaeger, grafana and prometheus containers: OpenObserve serves all
three signals and that stack existed only to read them.

Bugs fixed along the way

• getIntegrationTags returned [] for every OTEL integration — the branch
  tested "Open Observe", a string never present in the enum. The client filters
  the picker on tags, so no OTEL integration was selectable at all.
• Both observability adapters stripped cfg: with substring(3), leaving a :
  on the key. No cfg: reference in a Loki or OTEL baseUrl or credential had
  ever resolved. Every other adapter uses slice(4).
• TestConnection probed GET {baseUrl}/settings — an OpenObserve admin path
  that any other collector 404s, so a generic OTLP endpoint read as unreachable.
  It now posts an empty OTLP batch to the endpoint of the signal being tested:
  ingests nothing, 200 from a working receiver, 401 from one that rejects the
  credentials.
• settings.telemetry.* and the legacy variant were rejected by the settings
  connection check and by testObservibilityConnection, which switched on the
  raw variant while getSchema normalized — so a legacy row validated and then
  fell through to "Invalid variant".
• getProjectSetting never populated its cache, so a process that does not serve
  the get-all endpoint hit the database on every lookup.
• The JS logger api and the cloud logs block emitted nothing. The logger read
  only the legacy settings key, so a project configured through the new UI logged
  to the server console. Separately, the cloud logs block calls
  context.integrationFactory, which only the legacy interpreted path supplied —
  compiled routes hit a non-null assertion on undefined and threw. Both now
  resolve through one helper, which also stops the old code mutating the shared
  integration cache entry (the cross-labelling race in P1: compiled runtime logging lifecycle for OpenTelemetry and Loki #204).

Verification

End to end against NATS, Postgres and a live OpenObserve: a run published to
fluxify.trace.<projectId>.<runId> arrives as one trace with custom-block nesting
intact and span_status: ERROR on the failing block, route metrics carry the
project id, a project with no destination produces no stream at all, re-publishing
a runId yields one trace rather than two, and a stopped worker drains its backlog
on restart without replaying what it already exported. The per-signal probe was run
against all three live endpoints, including the bad-credential and unreachable
cases.

Repo lint 8/8; 598 tests pass, 21 of them new.

Notes for review

• Existing installs need a tag backfill. integrations.tags is a stored column
  written at create/update, so observability rows written before the
  getIntegrationTags fix carry '' and will not appear in a filtered picker
  until re-saved:
  update integrations set tags = 'logs,metrics,traces' where "group" = 'observability' and variant like 'Open Telemetry%'
• The stream-name header is deliberately not sent for metrics. Verified
  against a live OpenObserve: it ignores the header there and names the stream
  after the metric, so sending it would be a knob that silently does nothing. The
  project dimension for metrics is the fluxify.project.id attribute.
• No sendLogs/sendTraces/sendMetrics config booleans: per-signal opt-in is
  already expressed by which settings key points at the integration, and two
  switches for one thing eventually disagree.
• Logs still export from the execution process via the per-block connection, so
  log credentials still reach the data plane. Unifying that onto this path is
  follow-up work, not this PR.
• Route-level toggles for tracing and recording (Route settings page in the portal: tracing and recording toggles #207) and recording persistence
  with its endpoints (Execution recording: persist runs, list/detail endpoints and the portal viewer #208) are tracked separately.

🤖 Generated with Claude Code