feat(web): releases page

[Makisuo]

What

A Releases page: what shipped, per service, and whether it changed anything.

• /releases — filter sidebar (health band, environment, service; all derived client-side from the same rows), plain-text stats, per-service swimlanes with one dot per version at its first-seen time, and a table grouped by commit with day headers, expandable per-service children, and "this version vs. the rest of the service" deltas for error rate and p95.
• /releases/$commitSha?service=… — commit title and provider link, a comparison table against the other versions of the service in the same window, a versions rail, the service page's four golden-signal charts (with commit markers and a "This version / Other versions" toggle), and three issue lists: new on this version, regressed on it, still occurring.
• Sidebar entry under Monitor, after Services.

Why

Deploy information already existed as three fragments (the service page's markers and Recent-deploys rail, the services table's deploy cell, and fix verification's version split). None of them answered "what shipped across the fleet, and did it make anything worse?".

How

A release is a commit the moment it starts serving traffic. The service-overview rollups key on vcs.ref.head.revision as CommitSha, so every read here is a GROUP BY over the same hourly/minutely/raw splice the services list uses — no raw traces scan.

• packages/query-engine: releasesListQuery (one row per service/env/commit with counts, tdigest quantiles and apdex counts), releasesTimelineQuery (org-wide buckets for the swimlanes and the rollout share), releaseErrorFingerprintsQuery (error fingerprints on error_events_by_time keyed on service.version). Tests, catalog fixtures, and the SQL baseline are included; serviceOverviewWindows is now exported for reuse.
• apps/api: POST /internal/query-engine/releases and /release-detail bundle handlers. The detail runs versions, timeline, two timeseries (commitShas: [sha] and excludedCommitShas: [sha]) and the fingerprints concurrently.
• apps/web: adapter + atoms, a pure release-model.ts for the derivations (tested), and the two routes. Commit resolution reuses the bulk VCS lookup; the issues panel is one v2 list call keyed on the fingerprints.

Health bands reuse the services table's constants: 50 spans on each side before comparing, 2× error ratio with a 0.5pp floor for "errors up", +25% p95 for "latency up", and under 90% of the latest bucket for "rolling out" (also behind the span floor).

Reviewer notes

• The health search param is impact, not health: TanStack merges every route's search schema into one union, and /services already owns health with different literals.
• The comparison is same-window, this version vs. the merged remainder of the service. That handles a canary beside its predecessor; it does not attempt before/after on time.
• Not in this PR: the coalesce migration so service.version-only (CLI semver) deploys appear, delivered deploy events (GitHub/Cloudflare), and a "fixed by this version" list from verifications.
• Verified locally against the dev org: list, health filter, row expansion, detail page and the issues bridge all render from real data; every new endpoint returns 200. Scoped typechecks, lint, format and the touched packages' tests pass; the full suite was not run.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}