docs(observability): note that SENTRY_DSN is Fly-managed

Provisioned the Fly Sentry extension against opensentry-command so
backend errors now phone home to a sponsored Sentry Team plan (50k
events/mo, 100k perf units/mo, free for 12 months). No code changes
were needed — core/sentry.py was already wired to init from the
SENTRY_DSN env var; the extension just sets it for us.

Add a short note to the Configuration section so future maintainers
know the DSN is not something to re-enter by hand and point them at
the flyctl commands for dashboard access.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Sbussiso

AGENTS.md

@@ -40,6 +40,7 @@ Backend config is loaded from environment variables (see `backend/.env.example`)
 - `INACTIVE_CAMERA_CLEANUP_HOURS` — free caches for cameras offline this long (default 24)
 - `LOG_RETENTION_DAYS` — stream + MCP + audit + motion + notification log retention (default 90)
 - `OFFLINE_SWEEP_INTERVAL_SECONDS` — how often to mark stale rows offline (default 30)
+- `SENTRY_DSN` — error tracking. In production this is managed by the Fly Sentry extension (`fly ext sentry create -a opensentry-command`) which provisions a sponsored Team plan and auto-injects the secret; you rarely set this by hand. `app/core/sentry.py::init_sentry()` is a no-op when the DSN is absent, so local dev needs no extra config. Dashboard: `fly ext sentry dashboard -a opensentry-command`.
 
 Frontend config: `VITE_CLERK_PUBLISHABLE_KEY`, `VITE_API_URL`, `VITE_LOCAL_HLS`.