Around this alarm: the closed alarms nearby and the cameras that fire with this one

The context rail for one alarm. anchor is the alarm; graph.neighbours are the cameras that co-fire with its camera over 30 days (cached per site per hour; graph.status says ready / stale / unavailable and the rail still works without it); items are the CLOSED alarms in the window before_minutes before to after_minutes after the anchor, newest first, as three kinds: reviewed (an operator closed it), filtered (stopped before AI review by a pre-processing gate, DeepAlert and its confirmers) and agent_closed. scope=related (default) draws from the anchor's camera and its neighbours; scope=site from every camera at the site. counts always covers the whole window for the related cameras and the rest of the site, so the console can say how much is not shown. Open alarms are not returned (they are in the queue, and new ones arrive over the push stream). Open an item with GET /events/{event_id} and /clip-url. Central staff only (require_central_staff: owner, monitoring manager, operator, support, read-only), and tenant-scoped like every per-event read: an alarm outside the caller's scope and an unknown id are both 404, and only cameras the caller may see are read. ALARM_CONTEXT_ENABLED off answers 200 status: "disabled" with nothing else, before any alarm-context database work (authentication and the caller's scope load still run): show no rail. A feed or counts query that fails or hits its 3 s deadline answers 200 status: "degraded" with no items: say the rail is unavailable and retry later. This is an optional-rail fallback, not an end-to-end latency guarantee.