feat(selfhost): expose REES analyzer controls and validation

[JSONbored]

Context

REES is wired as an external review-enrichment service with a request-level analyzers field and several analyzers already present. Operators need to know which analyzers are available, how each is enabled/disabled, and whether the self-host Docker stack should run REES locally instead of relying on a hosted/Railway service.

Parent: #1680

Requirements

• Inventory current REES analyzers and their runtime dependencies.
• Define operator-facing config for enabling/disabling analyzers individually.
• Decide whether REES should be optional sidecar/profile in the self-host Docker stack, hosted-only, or both.
• Add tests for analyzer selection, skipped/degraded status, timeout behavior, and prompt-splice safety.
• Add Sentry/structured-log context for REES failures so broken enrichment is visible.

Deliverables

• Analyzer matrix with names, purpose, dependencies, default state, and expected failure mode.
• Config wiring proposal or implementation for per-analyzer controls.
• Self-host docs for GITTENSORY_REVIEW_ENRICHMENT, REES_URL, REES_SHARED_SECRET, REES_TIMEOUT_MS, and analyzer selection.
• Tests covering individual analyzer allowlists and degraded responses.

Acceptance criteria

• Operators can tell exactly which REES analyzers are active for a review.
• An analyzer failure never poisons the whole review; it is marked degraded and visible in logs/Sentry.
• If REES remains outside the main image, the docs explain why and how to run it safely.
• No labels beyond maintainer-only.