fix(AR-013): reap tracks on the evidence watermark, not the tracker's clock

The registry closed a track when the *tracker's* timestamp passed
`track_extinction_sec`. But votes arrive from the matcher, which is a separate
KPN node behind a channel, and much the slower of the pair. Backpressure —
working exactly as AR-004 intends — turns that channel's depth into lag, so
the tracker's clock can be far ahead of the last frame anybody has voted on.
Tracks were therefore closed before their evidence arrived: the votes landed
on ids that no longer existed, were counted as dropped, and the track was
emitted unowned or not at all.

The symptom is the part worth remembering: **a deeper channel produced fewer
identifications, from identical input.** On the SuperHero fixture, 5 actors /
16 windows at depth 32 against 3 actors / 5 windows at depth 10322; through
the replay harness, capacity 32 gave 5 actors and 10322 gave 0. A throughput
knob was silently changing the answer, which makes every sweep tuned against
it suspect.

The fix is not to bound the channel against `track_extinction_sec` — that
makes an algorithm constant police a throughput knob and leaves the result a
function of scheduling. It is to reap on an evidence watermark: the matcher
advances it as it folds each frame in, and a track is only finished once
everything up to its extinction point has actually been voted on. Same device
`SceneBoundaries::scored_through()` uses for the AR-010 join — a consumer past
that point is asking about frames nobody has looked at yet, and the honest
answer is to wait rather than guess.

Association keeps the tracker's clock, and separating the two is the other
half. They answer different questions: "may this detection link to that
track?" is asked now, about a box seen `track_extinction_sec` ago; "is that
track finished?" cannot be answered until every vote is in. Deferring
association to the evidence clock — which deferring the erase alone did — left
retired tracks associable for as long as the matcher lagged, so a new face
re-associated onto a long-dead track and two people merged into one window.

The watermark is monotonic and only ever *delays* a reap, so no window is
extended by it: AR-013's "a window ends at the last sighting, never after" is
a property of `emit_locked`, which takes `last_seen` and never `now`.

`dropped_votes` is exposed and reported — by main at shutdown and through the
replay bindings — because this failed silently for as long as it did precisely
because nothing counted it. It warns rather than aborts: a dropped frame means
the output describes footage nobody analysed and is always wrong, while a
dropped vote degrades a claim without falsifying it, and there is no
measurement yet of how often it happens on real content.

replay.py's channel capacity stops being the whole film. It was sized that way
to dodge a PyNode overflow drop that AR-004 has since replaced with parking,
and removing backpressure that way is what made the defect above so extreme.

Tag separators in kpn_bindings.cpp corrected to pipes between requirement
types, which the traceability gate was reporting as diagnostics; the matrix is
regenerated and reports 0 orphan tags.

149/149.

TRACES: AR-004, AR-012, AR-013, AR-025 | VR-011 | SR-002 | PR-002

src/main.cpp

@@ -516,6 +516,45 @@ int main(int argc, char** argv) {
             std::cerr << "\n";
         }
 
+        /// TRACES: AR-025, AR-012 | SR-002
+        // How often the registry was asked about a track it had already reaped.
+        //
+        // A vote is dropped when the matcher lags the tracker by more than
+        // track_extinction_sec of FILM time. The two are adjacent nodes with a
+        // 16-deep channel between them, and the matcher is much the slower of
+        // the pair (a GEMM over the whole gallery against a Hungarian solve over
+        // a handful of boxes), so that channel runs full and the lag is close to
+        // its depth. In frames:
+        //
+        //     lag_sec  ~=  channel_depth / sample_fps
+        //
+        // At the default sample_fps of 1.0 that is ~16 s against a 5 s window,
+        // so votes CAN be dropped here, and each one is identity evidence that
+        // never reached the track it belonged to -- presence under-reported, in
+        // a way that reads as a recognition miss.
+        //
+        // Reported rather than fatal, deliberately, and the distinction from the
+        // dropped-frame case below is real: a dropped frame means the output
+        // describes footage nobody analysed, which is always wrong. A dropped
+        // vote means one observation of a track went missing, which degrades a
+        // claim without falsifying it. There is also no measurement yet of how
+        // often it happens on real content -- so this prints the number that
+        // would justify a harder line rather than presuming it. See VR-017.
+        if (registry) {
+            const int dv = registry->dropped_votes();
+            if (dv > 0) {
+                std::cerr << "[registry] WARNING: " << dv << " identity vote(s) "
+                             "arrived for already-reaped tracks. The matcher is "
+                             "lagging the tracker by more than track_extinction_sec ("
+                          << cfg.track_extinction_sec << "s) of film; presence is "
+                             "under-reported. Raise --track-extinction or reduce the "
+                             "face_tracker/identity_matcher channel depth.\n";
+            }
+            std::cerr << "[registry] belief_swaps=" << registry->belief_swaps()
+                      << "  actor_conflicts=" << registry->actor_conflicts()
+                      << "  dropped_votes=" << dv << "\n";
+        }
+
         bool dropped = false;
         {
             std::lock_guard<std::mutex> lk(event_mtx);