admin: surface corr_gate_veto on the correlation-debug endpoint (#115)

corr_gate_veto was written to corr_debug but the admin endpoint's whitelist (_call_summary + the summary tally) never surfaced it, so the last commit's whole point -- measuring window #4 instead of guessing -- would have produced nothing to read. Add it to both. Also softened the docstring's remaining overclaim: whether the active-only ctx[recent] limitation explains the 2/24 window-3 misses is unanswered, not confirmed -- read corr_gate_veto next window instead of asserting a guess again.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix

drb-c2-core/app/routers/upload.py

@@ -150,11 +150,12 @@ def _recent_incident_on_same_talkgroup(ctx: dict) -> bool:
     fix needs a dedicated Firestore query that is not status/capacity
     filtered — a new read, out of scope for this pass.
 
-    This does NOT explain the 2/24 unexplained gate misses in the window #3
-    measurement — re-review found a code-level explanation for both instead
-    (see `_call_is_substanceless`'s `incident_type`/`reassignment` branch and
-    the scene-level severity/tags fields the call-doc alone doesn't show), so
-    this limitation is believed inactive so far, not a live loose end.
+    Whether this limitation explains the 2/24 unexplained gate misses in the
+    window #3 measurement is UNANSWERED, not confirmed either way — a prior
+    pass here claimed a "confirmed explanation" for both that turned out to
+    be self-contradictory. Read `corr_gate_veto` (written to corr_debug on
+    every escalation of this exact disagreement shape — see the caller) in
+    the next measurement window instead of guessing from the raw dump again.
     # TODO(server-26#115): add a talkgroup-scoped incident lookup (any
     # status, no capacity filter) if a future measurement window pins a real
     # gate miss on a resolved/capped same-talkgroup incident.