platform: error-reporting audit and baseline pass

[zgeoff]

#328 adopts Bugsink (self-hosted, Sentry-SDK-compatible) as the error backend; this is the audit and baseline pass that makes it useful. Per docs/architecture/error-handling.md, the Sentry SDK backed by Bugsink is the only path to the error backend. The TypeError: immutable proxy crash fixed in #371 existed only as an unstructured stack interleaved in fly logs.

Scope

• wire the Bugsink DSN in every deployable app: app-web plus the six services (activity, avatar, email, session, user, verification)
• capture unhandled route/server errors and unhandled rejections at the central hooks (service interceptor, app-web root error boundary) — never captureException where those already cover
• route alerts somewhere visible
• audit for swallowed exceptions that should report; confirm the trace id (x-trace-id / withTraceContext) rides on captured events for log correlation

Acceptance

• a thrown fault in each app appears in Bugsink as a structured event with its trace id
• an unhandled promise rejection is captured
• the audit lists any remaining swallow points with a follow-up

Notes

apps/design-reference was removed (#453), so it is not a target. Complements the logging audit (#380) and the trace/metric audit (#432).

[zgeoff]

Issue-audit body refresh: Corrected the backend (GlitchTip → Bugsink, matching #328 and docs/architecture/error-handling.md) and the DSN target list (app-web + the six services; design-reference is deleted), and tied capture to the central error hooks and trace-id correlation. Previous body preserved in the edit history.

[zgeoff]

Audit results

Reporting wiring. All nine deployables now carry a Bugsink project DSN (service-email and service-replay were missing; provisioned). Central hooks were already in place at all three tiers: the service onError interceptor (with traceID tag), app-web's query caches, and the root error boundary. Unhandled rejections and uncaught exceptions are captured by SDK defaults in all three runtimes (@sentry/bun, @sentry/node, browser globalHandlers) — verified against 10.63.0, no code change needed.

Alerts. Every project alerts to the Discord alarms channel (per-project webhook config; URL on the bugsink-discord-webhook vault item). Email alerting via Resend SMTP lands with #588.

Swallow points. The RPC-handler path is clean: every service handler catch either rethrows to the interceptor or converts an expected constraint violation into a domain error. Remaining swallow points, each with a follow-up:

• platform: report background-work faults to the error backend #589 — background work never reaches the error backend: the replay worker loop, the email job queue (onError and silent dead-letter after retry exhaustion), the queue drains, and the hourly sweep entrypoint (which never initializes Sentry at all). The highest-impact gap.
• game: surface persistent checkpoint-flush failures to the error backend #595 — the idle-client checkpoint submitter silently drops persistently failing flushes (fix in fix(#595): report stalled checkpoint flushes and trace-tag stream errors #599).
• web: correlate checkpoint-stream error reports with service trace ids #596 — browser checkpoint-stream error reports carry no trace id, so they can't be joined to the service-side event (fix in fix(#595): report stalled checkpoint flushes and trace-tag stream errors #599).

Judged fine as-is: app-web's best-effort logout .catch, the loader prefetch .catch (query cache still reports), step-up token verification, and the replay serve SIGTERM catch (exit code signals the orchestrator).

Trace correlation. Service-side events carry traceID; #599 extends that to the browser's checkpoint-stream captures. The remaining browser capture sites (query cache, root boundary) fire mostly for failures with no corresponding service event, so no trace id is attached there by design.