fetchData/fetchJsonEachRowAsNormalizedJson now parse the read_bytes
field out of ClickHouse's X-ClickHouse-Summary response header into
metadata.readBytes, only when the header is present and parses
cleanly. Needed by the OTel clickhouse-query span attribute
(plans/39-otel-trace-export.md) but has no OTel dependency itself —
this package stays otel-agnostic.

Co-Authored-By: duyetbot <bot@duyet.net>

…quest path

Root span: otelMiddleware in start.ts wraps every request in a
dashboard-request span (positioned after Sentry so it covers
security-headers/auth/the route handler), warming the memoized OTel
singleton from the Worker env and flushing inline before the response
returns (no waitUntil available here, same constraint sentryMiddleware
already documents).

Child span: query-executor.ts's three ClickHouse execution call sites
(executeTableConfig, executeChartQuery, executeMultiChartQuery) each
wrap their fetchData/fetchJsonEachRowAsNormalizedJson call in a
clickhouse-query span via withClickHouseQuerySpan. This is the actual
load-bearing @chm/clickhouse-client seam (8 route handlers funnel
through it) — not clickhouse-helpers.ts's fetchDataWithHost, which has
no production callers.

AsyncLocalStorageContextManager (registered only when export is
enabled, see exporter.ts) propagates the parent/child relationship
across the async chain without manual context threading. There is no
distinguishable "system-table-read" seam beneath clickhouse-query
(fetchData makes one HTTP call per invocation), so the span tree is
two levels (dashboard-request -> clickhouse-query) rather than three,
per the plan's own documented fallback.

Co-Authored-By: duyetbot <bot@duyet.net>

Adds the env var to .env.example and the environment-variables
reference (self-host docs), with a Jaeger OTLP/HTTP example and the
workerd (HTTP-only, no gRPC) constraint. Declares
@opentelemetry/{api,context-async-hooks,exporter-trace-otlp-http,
resources,sdk-trace-base,semantic-conventions} in apps/dashboard's
package.json — app-side only, not packages/clickhouse-client.

NOTE: bun.lock is NOT updated by this commit (bun install could not be
run in this worktree — see task constraints). The packages are already
present in the shared node_modules and all otel tests pass against
them, but a real `bun install` is needed before a frozen-lockfile CI
job (cloudflare.yml, test.yml, a11y.yml, etc.) will pass. Flagged in
the handoff report.

Co-Authored-By: duyetbot <bot@duyet.net>

start.ts: wrap next() in an async arrow (not a bare () => next()) so
withSpan's fn parameter, typed Promise<T>, actually type-checks —
TanStack's next() return type isn't structurally a Promise. Caught by
bun run type-check (bun test alone never runs tsc).

Adds span-nesting.test.ts: registers a real
AsyncLocalStorageContextManager and proves a clickhouse-query span
started after an await inside dashboard-request's callback still comes
out as its child (parentSpanContext matches), and that two concurrent
requests' spans don't cross-contaminate. This verifies the
withSpan/ALS composition nests correctly; the residual (that TanStack's
own next() chain preserves the same ALS store end-to-end) is only
confirmed against a real collector, not by this unit test.

Co-Authored-By: duyetbot <bot@duyet.net>

apps/dashboard/bun.lock was missing the OTel deps added by this PR,
causing bun install --frozen-lockfile to fail in CI. Rebased onto
current main (clean, no conflicts) and regenerated the lockfile.

Co-Authored-By: duyetbot <bot@duyet.net>