Add Sentry error monitoring (env-gated DSN, gRPC + HTTP gateway interceptors)

[SyniRon]

Wire the getsentry/sentry-go SDK with an env-gated DSN. sentry.Init
in cmd/root.go (or servers/server.go), defer sentry.Flush(2 * time.Second)
on shutdown.

Wrap both the gRPC server and the HTTP gateway with Sentry interceptors
so panics and returned errors get captured with full request context.

Production-only via absence of SENTRY_DSN — no DSN, no Sentry init, no
capture. Local and dev environments don't need to opt out explicitly.

Pairs with similar work in adjacent 7Cav tools; whichever lands first
sets the pattern (config key naming, scope tags, sample rate, etc.) for
the others to mirror.

[SyniRon]

This was generated by AI during triage.

Triage Notes

Code state:

• No sentry references anywhere — SDK would be a net-new direct dependency.
• Existing logging is package-level Warn.Printf / Error.Println (grpclog-style stdlib loggers). No structured logger to hook into. Sentry integration has to decide whether to capture only at interceptor boundaries, or also wrap existing Error.Println sites.
• The release-version baking already wired via -ldflags="-X github.com/7cav/api/servers.version=<tag>" is a free hook for sentry.Init's Release field — use it.

Why ready-for-human, not ready-for-agent:

The body's "whichever lands first sets the pattern (config key naming, scope tags, sample rate, etc.) for the others to mirror" makes the pattern-setting decisions the load-bearing part of this work. A human picking them once and propagating to the other 7Cav repos is cheaper than an agent picking them per-repo and the maintainer reconciling later. Not blocked — both sides are racing, neither gates the other.

Knobs to decide deliberately during implementation:

• Env vars beyond SENTRY_DSN: SENTRY_ENVIRONMENT, SENTRY_RELEASE (the latter can default to the ldflags version string), SENTRY_TRACES_SAMPLE_RATE?
• Tag schema. service:api and route:/api/v1/... are easy wins. api_key_id is tempting for "top consumers" attribution but has PII / scope-leak considerations — worth a deliberate call.
• Whether existing Error.Println sites also sentry.CaptureException, or only the interceptor/recover paths.
• Sample rate for errors (almost certainly 1.0); whether to enable any transactions/perf tracing (probably no for v1).
• Test-environment opt-out — the env-gate via missing SENTRY_DSN covers local dev, but what about CI? Make sure CI never has the var set.

Whatever shape lands here should be the template the adjacent 7Cav tools mirror. Worth a short notes line in CLAUDE.md once it does, so the next repo can copy without re-deriving.