observability(rees): capture degraded analyzer runs in Sentry

[JSONbored]

Part of #998. Related: #1684 and #1499.

Context

REES intentionally fails open: if one analyzer throws or times out, buildBrief() marks that analyzer degraded, returns partial: true, and still gives the review engine a usable brief. That is the right product behavior, but it can hide analyzer outages until someone notices missing findings.

This issue makes analyzer degradation visible in Sentry without changing the fail-open contract.

Requirements

• Keep REES behavior fail-open: analyzer failure must still return a partial brief instead of failing the request.
• Capture analyzer throw/timeout events only when Sentry is enabled.
• Do not attach request bodies, diffs, tokens, authorization headers, or raw prompt/review content to Sentry.
• Tag events with safe routing fields only: analyzer name, repo, PR number, head SHA when present, release, environment, and timeout budget.
• Use stable grouping/fingerprints so repeated failures from the same analyzer group together instead of fragmenting by variable message.
• Preserve current no-DSN behavior: unset SENTRY_DSN remains fully inert.

Deliverables

• REES Sentry helper for analyzer degradation capture.
• Instrument review-enrichment/src/brief.ts catch paths for analyzer errors and timeouts.
• Tests that prove the returned brief is still partial/fail-open and that Sentry receives sanitized analyzer context.
• Tests that prove unset Sentry config is a no-op.
• Brief troubleshooting docs for finding degraded analyzers in Sentry.

Acceptance criteria

• A forced analyzer timeout produces a Sentry event tagged to that analyzer and PR while the API still returns partial: true.
• A forced analyzer exception produces a grouped Sentry event with sanitized context.
• No sensitive request payload fields leave the process.