Observability: Sentry error & performance instrumentation (optional per-deployment DSN)

[JSONbored]

Part of #975. Related: #982 (self-host dashboard / observability), #983 (convergence & migration).

Context

Add Sentry (errors + performance + distributed tracing) as an optional, per-deployment observability layer for the converged gittensory app. It plugs straight into the per-deployment-config model: an optional SENTRY_DSN binding — the hosted service uses gittensory's DSN; self-hosters supply their own; unset = Sentry is fully off (zero-config). Uses @sentry/cloudflare (Workers-native); Sentry's OSS / sponsored plan covers the hosted side.

It complements the existing Cloudflare observability + audit/usage telemetry by adding error grouping & alerting, distributed tracing of the review pipeline (webhook → queue → dual-AI → gate → post), release health, and — critically — per-installation error/perf slicing, which closes the "no per-tenant observability" gap.

Deliverables (tracked as sub-issues)

• SDK integration + optional DSN seam (off by default)
• Privacy scrubber (beforeSend) — non-negotiable redaction
• Review-pipeline tracing + per-installation tagging
• Self-host + hosted wiring + docs

Acceptance criteria

• With no SENTRY_DSN, Sentry is fully inert — zero behaviour change and zero added latency.
• With a DSN, errors + traces flow, grouped and sliceable per installation.
• No PR content, rubric, guardrail paths, tokens, BYOK keys, or wallet/reward/scoring context ever leaves in a Sentry event (verified by tests).
• Self-hosters enable their own Sentry with one env var; docs cover it.

Notes

• Add the thin seam during convergence so it instruments the CONVERGED engine, but keep it dormant/optional until the converged stack is stable. Not a convergence blocker — a quality layer on top.
• Privacy scrubbing reuses the existing redaction discipline (the public-comment redactors / sanitizePublicComment) so it stays in sync with the comment surface.

Current hardening child issues

• observability(rees): capture degraded analyzer runs in Sentry #1732 — REES degraded analyzer Sentry capture
• observability(selfhost): add Sentry cron monitors for scheduled work #1733 — Sentry cron monitors for scheduled self-host work
• observability(tracing): add sampled Sentry spans for review latency #1734 — sampled Sentry spans for review latency
• observability(rees): standardize Sentry tags and fingerprints #1735 — REES Sentry tags and fingerprints
• ci(release): validate Sentry releases after deploy #1736 — post-deploy Sentry release/source-map validation
• observability(ui): add browser Sentry with private source maps #1737 — browser UI Sentry with private source maps
• observability(worker): add Cloudflare Sentry release and source maps #1738 — Cloudflare Worker Sentry release/source maps
• observability(alerts): define Sentry ownership and alert rules #1739 — Sentry alert ownership and alert rules

Suggested first focus: #1732, because REES currently fails open by design and analyzer degradation can otherwise stay invisible.