Add request phase timing design spec

[jevansnyc]

Closes #1068.

Design spec for per-request phase attribution: TS-emitted Server-Timing subtimings plus Tinybird access telemetry percentiles.

What the spec covers

• A core RequestTimings type (closed phase enum, saturating monotonic spans, cheap-clone handle) collected on every request with no flag, carried through request extensions, the streaming body closure, and post-send emission.
• Header spans for the pre-first-byte phases: ts-total, ts-appbuild, ts-filter, ts-geo, ts-kv, ts-origin, ts-c2. Appended in apply_finalize_headers, gated by a new observability.server_timing_enabled flag. Browsers expose the header via PerformanceResourceTiming.serverTiming, so publisher RUM tooling picks up the breakdown with no integration work.
• Body-phase fields the header cannot carry (auction_wait_ms, stream_ms, resp_bytes) flow to Tinybird only.
• Access telemetry: extends the reserved access_logs_raw datasource with phase columns, route_class, c2_state, ts_version, and pop; one sampled NDJSON row per request emitted strictly after the last body byte, reusing the auction sink pattern; unwires the settings guard that rejects tinybird.access_enabled.
• A rider that dedupes the two per-request geo hostcalls into one (finalize reads the stashed request-phase result).
• One percentile endpoint pipe, and a standalone performance dashboard (separate from the revenue and auction dashboards, lives in the telemetry repo).
• Rollout order, including the one external unknown: verifying the fronting delivery layer passes an appended Server-Timing through.

Motivation: a production stall window (publisher redacted in the spec) added a uniform ~600 ms to every application-path request and could not be attributed without a live probing session. With this in place the next window names its phase in one response header or one dashboard query.

Spec only; no runtime code changes in this PR. Implementation plan follows.

[jevansnyc]

The direction is sound, but I found correctness blockers around the finalization boundary and total-time snapshot, plus naming, privacy, telemetry-delivery, configuration, and query-model concerns. I would address the blocking items before treating the design as implementation-ready. Inline comments contain concrete suggested changes.

[jevansnyc]

Round 2: the first-round corrections materially improve the design. The freeze point, stored snapshot, template-cache naming, rollback plan, and confirmed ingestion response are now much clearer. I still see three implementation-blocking issues: buffered publisher paths invalidate the body-phase math, the Tinybird schema/query model is invalid as written, and the cache-replay exclusion is not conservative enough. The remaining inline comments cover geo/context propagation, privacy, adapter parity, validation, and operational behavior.

[ChristianPavilonis]

Summary

The observability goal and Fastly freeze point fit the project, but the design and companion implementation plan assume several carriers and adapter hooks that the current code does not provide. The inline findings identify the architectural changes needed before implementation can proceed without losing routes or reporting misleading data.