feat(anpr): poll snapshots until a confident plate, so auto-exit works

The ANPR bridge took ONE snapshot at the camera's vehicle-alarm instant — but the
alarm fires as the car APPROACHES, so that frame's plate is small/blurry/half-in-
frame and ANPR returns a low-confidence misread ('111'@0.20). The manual test reads
the SAME car at ~100% because by then it's STOPPED at the barrier, well-framed. So
subscriber auto-exit silently never fired (read below the 0.85 floor → ignored).

Fix (the car-stops-at-the-barrier insight): the bridge now PULLS A FRESH FRAME every
ANPR_POLL_MS (1000) and re-runs ANPR until one clears VISION_ENTRY_MIN_CONFIDENCE, or
ANPR_POLL_WINDOW_MS (8000) elapses (drove off / non-subscriber → give up cleanly).
- One loop per camera (#polling set) — the camera's ~1Hz alarm re-fires JOIN the
  running loop instead of spawning N concurrent loops.
- Fresh camera.captureSnapshot each tick, NOT captureSnapshotShared (its 1.5s TTL
  would re-serve the same bad approach frame).
- Camera-level debounce stamp moved to AFTER a successful emit (suppresses re-fires
  for ANPR_DEBOUNCE_MS once we've acted), not before the loop.

VERIFIED on hardware (DS-2CD1047G3H-LIU exit lane): 7 garbage approach frames →
AA890XX@0.999 at the barrier → signed vehicle_exit. Still advisory + fail-soft; a
barrier never opens on a low-confidence read. anpr-entry.test.ts +1 (poll
escalation low→low→high); 169 server tests green. Documented in
lane-presence-and-anpr-entry + the lpr-camera camera-fault writeup.

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

wiki/concepts/lane-presence-and-anpr-entry.md

@@ -62,7 +62,23 @@ then does the gated entry/exit + barrier open. Constructed in `server.ts` (the f
 above the hik-alarm registration so the bridge can take `subscriptionFlow`). Fail-soft throughout —
 any snapshot/vision error degrades to the subscriber's card/QR, never throws into the push handler.
 Two new env knobs: `VISION_ENTRY_MIN_CONFIDENCE` (0.85), `ANPR_DEBOUNCE_MS` (12_000). Covered by
-`anpr-entry.test.ts` (7) + `hikvision-alarm.test.ts` wiring (3).
+`anpr-entry.test.ts` + `hikvision-alarm.test.ts` wiring.
+
+> **POLL-until-confident (2026-06-27).** The single-shot capture above was upgraded to a **poll
+> loop**. The camera fires its vehicle alarm the INSTANT motion starts — the car is still
+> APPROACHING, so the first frame's plate is small/blurry/half-in-frame and ANPR returns a
+> low-confidence misread (observed live on the exit lane: `'111'`@0.20, `'AE18671'`@0.19 …, while
+> the manual `test-anpr` on the SAME stopped car read `AA890XX`@1.00). The car then STOPS at the
+> barrier waiting for it to open — the stationary, well-framed moment the test reads at ~100%. So
+> the bridge now **pulls a FRESH frame every `ANPR_POLL_MS` (1000) and re-runs ANPR until one clears
+> the floor, or `ANPR_POLL_WINDOW_MS` (8000) elapses** (car drove off / non-subscriber → give up
+> cleanly). One loop per camera (`#polling` set) so the ~1Hz alarm re-fires JOIN it, not spawn N;
+> each tick is a fresh `camera.captureSnapshot` (NOT `captureSnapshotShared`, whose TTL would
+> re-serve the same bad frame). VERIFIED on hardware: 7 garbage approach frames → `AA890XX`@0.999
+> at the barrier → signed `vehicle_exit`. This is what made subscriber **auto-exit** actually work
+> on the DS-2CD1047G3H-LIU (whose alarm fires on approach, not at the readable moment — see
+> [[lpr-camera]] "auto-enter but don't auto-exit"). Still advisory + fail-soft; a barrier never
+> opens on a low-confidence read.
 
 The goal (narrowed deliberately — see Rejected below): **a subscriber's plate, read by the lane
 camera, admits them through the same gated flow a QR/card scan uses.** Scope was cut to subscribers

wiki/entities/lpr-camera.md

@@ -2,7 +2,7 @@
 type: entity
 tags: [parking, hardware, readers, offline-first]
 sources: [parking-system-architecture]
-updated: 2026-06-26
+updated: 2026-06-27
 ---
 
 # LPR Camera
@@ -74,6 +74,21 @@ fixes — **don't assume it's a momentary blip**:
   status); the main encoder was simply never free. A retry loop **cannot** fix this — it just delays
   the failure.
 
+> **Sharper finding (2026-06-27, same DS-2CD1047G3H-LIU).** Re-probed `10.0.10.13` directly after a
+> camera reboot with every web/live-view connection closed. **Sub (102): 10/10 rapid back-to-back
+> pulls → 200** (~50 ms, ~14.7 KB) — flawless even with NO delay, harder than the live ANPR cadence.
+> **Main (101): 3/3 → 503 in ~20 ms** — an *instant* reject, not a timeout. So main isn't merely
+> "saturated/busy" on this model — its snapshot endpoint is **structurally unavailable**; **sub (102)
+> is mandatory**, not just preferable. SEPARATELY, the camera 503s on **any** stream when its
+> **connection slots are exhausted** — a human holding the web UI / live-view, or parallel
+> main-stream experiments, consume slots; a **reboot clears stuck slots**. This was the actual cause
+> of the **2026-06-27 "subscribers auto-enter but don't auto-exit"** scare: manual main-stream
+> testing held the exit camera's slots → the system's sub-stream snapshot pulls got "Device Busy" →
+> the ANPR exit read never got a frame → no auto-exit. **NOT a code/flow bug** — the subscription
+> exit logic, camera→relay binding, and `stream: "2"` config were all correct (auto-exit/entry pairs
+> were clean before the test storm and after the reboot). (Also recorded as the LLM memory
+> `g3h-main-stream-snapshot-503`.)
+
 **The fix that actually works: snapshot from the SUB stream.** The Hikvision ISAPI channel id is
 `<channel><stream>` (e.g. ch1 main = `101`, ch1 **sub = `102`**). The driver now has a **`stream`
 config field** (`1` = main, default for back-compat; `2` = sub). Set the G3H camera to **Sub (02)** in
@@ -126,6 +141,58 @@ Center**, then **Alarm Settings → Alarm Server**, makes the camera **HTTP-POST
   use it directly; this `DS-2CD1043G2`
   does not, so the server pulls the frame and hands it to the [[opencv-anpr-service|vision service]].
 
+### "Subscribers auto-enter but don't auto-exit" — a 4-layer CAMERA fault, NOT our code (2026-06-27)
+
+A long debugging session on the **DS-2CD1047G3H-LIU** exit camera (`10.0.10.13`, exit-lane). The
+symptom: subscribers (e.g. Caca) auto-entered via ANPR fine but **never auto-exited**. **Every
+assumption about *our* code was wrong; all four real causes were camera-side.** Method that finally
+cracked it: a **dumb HTTP sink** (`scratch-camera-sink.py`) the camera's Alarm Server was pointed
+at, to see — verbatim — what the camera actually sends, independent of our app's parsing/acceptance.
+
+The wrong turns, and what was actually true:
+
+1. **Wrong assumption: "the exit camera 503s, so harden the snapshot retry / reduce load."** The 503
+   storm in the data was mostly **manual main-stream testing**: on this G3H, `channels/101/picture`
+   (MAIN) **503s instantly every time** — structurally unavailable, not "busy" — while `102` (SUB)
+   serves 10/10 rapid pulls cleanly. AND the camera **503s on *any* stream when its connection slots
+   are exhausted** (a held web UI / live-view, parallel experiments); a **reboot clears stuck slots**.
+   So the snapshot retry/flow code was fine. See [[#HTTP 503 "Device Busy"]] + the
+   `g3h-main-stream-snapshot-503` memory. (The exit/subscription FLOW logic, camera→relay binding,
+   and `stream:"2"` config were all correct the whole time — verified: clean entry/exit pairs before
+   the test storm, and after the reboot.)
+
+2. **The actual blocker #1 — the exit camera never POSTed at all.** `alarmPushEnabled=true` in our
+   config, but `10.0.10.13` had sent **ZERO** alarms ever (entry cam `.12`: 1126). The sink received
+   nothing from `.13`; our `/event` endpoint logged no rejections either → the camera wasn't sending.
+   Cause found in the camera's own **Diagnose Information** dump: **`Main Db is broken` /
+   `db_restore failed` / `Going to reset cfg`** — the camera's internal config DB (`ipc_db`) was
+   **CORRUPT**, plus repeated reboots. A broken config DB means the event→linkage→push pipeline can't
+   reliably read its own config, so it silently never POSTs. **Fix: factory-reset the camera** (rebuilds
+   `ipc_db`), then reconfigure. (If corruption returns after a clean reset → failing flash → RMA.)
+
+3. **Wrong assumption: "missing gateway/DNS blocks the push."** A documented Hikvision note says a
+   gateway is needed even same-subnet — but here it was **inverted**: the WORKING cam `.12` has NO
+   gateway/DNS; the broken `.13` HAD both. Red herring. Gateway/DNS was not the cause.
+
+4. **The actual blocker #2 — after reset, the camera pushed PLAIN MOTION, not vehicle.** Post-reset
+   `.13` POSTed `<eventType>VMD</eventType>` with **no target tag**. The backend gates on
+   `target == "vehicle"` (`hikvision-alarm.ts` `isVehicleActive`, matches `<targetType>` /
+   `<detectionTarget>` / `<objectType>`), so a plain-motion push is **ignored** → bridge never fires.
+   The working `.12` sends `eventType=VMD` **with `target=vehicle`**. The difference is the AcuSense
+   **Detection-Target = Vehicle** filter ON the Motion event — defaulted OFF after factory reset.
+   **Fix: enable Vehicle target classification** on `.13`'s Motion Detection. Confirmed live: a real
+   drive-through then POSTed `<eventType>VMD</eventType> … <targetType>vehicle</targetType>` — exactly
+   what the backend needs. (So "VMD/Motion" IS the right event for this camera class; it's the *target
+   filter* that matters, not switching to a different event type.)
+
+**Takeaways:** (a) a camera that's silently not-pushing looks identical to "fine" in our logs — the
+sink-to-prove-it-sends method is the fastest disambiguator; flagged as an observability gap (a
+`alarmPushEnabled=true` camera with 0 pushes ever should be a surfaced condition, like the
+[[device-status-monitoring|reader-liveness]] fix). (b) For ANPR the camera must send a **vehicle
+`targetType`** — verify the push body, not just the UI toggles. (c) Hikvision config-DB corruption
+is real; factory reset is the cure. None of this was a code bug. See
+[[lane-presence-and-anpr-entry]] for the push→bridge→exit path.
+
 ### Gotchas learned the hard way (2026-06-22 field session)
 
 Several traps surfaced trying to get a real camera to push. In order of how long each cost:

wiki/log.md

@@ -1717,3 +1717,39 @@ Gotchas that bit us (now in [[appliance-provisioning]] §7 + gotchas 7–11): `c
 (blank registry account → `no basic auth credentials`); user-mode + `/etc/komodo` root_directory →
 `Permission denied`; config key is **`core_address`** singular. [[appliance-provisioning]] §6 split:
 §6 = engine, §7 = Komodo deploy (PRIMARY) with §7c manual `booth.sh` break-glass.
+
+## [2026-06-27] query | "Subscribers auto-enter but don't auto-exit" → NOT a bug; G3H main-stream snapshot is structurally dead
+
+Investigated via a read-only VACUUM copy of the dev DB. Caca subscriber's ledger: clean
+entry/exit pairs until ~16:38, then 6 entries + 0 exits. Traced to the **exit camera 10.0.10.13
+(DS-2CD1047G3H-LIU)** producing only 2 reads ever (vs 60 on the entry cam) — every exit-direction
+snapshot after 16:38 was **HTTP 503 "device busy"**, so the ANPR exit read never got a frame →
+no `emitRead` → no auto-exit. The subscription-flow exit logic, camera→relay binding (relay 2 =
+exit, anpr on), and `stream: "2"` config were all **correct**. Direct hardware re-probe after a
+camera reboot + closing web connections: **sub (102) 10/10 rapid → 200 (~50 ms)**, **main (101)
+3/3 → 503 in ~20 ms (instant reject)**. So main-stream snapshots are **structurally unavailable**
+on this model (sub mandatory), and the 503 storm was **connection-slot exhaustion from manual
+main-stream testing** holding the camera's slots (reboot clears). Recorded in the
+the `g3h-main-stream-snapshot-503` LLM memory + a 2026-06-27 sharper-finding note in [[lpr-camera]]
+("503 Device Busy"). No code changed — diagnosis only.
+
+## [2026-06-27] query | "Auto-exit" RESOLVED — a 4-layer CAMERA fault on the G3H, never our code
+
+Continuation of the above. Drove the full diagnosis to ground using a **dumb HTTP sink**
+(`scratch-camera-sink.py`) the exit camera's Alarm Server was pointed at, to capture the verbatim
+push. Every assumption about *our* code was wrong; all real causes were camera-side on the
+**DS-2CD1047G3H-LIU** (`10.0.10.13`):
+(1) 503s were mostly **manual main-stream testing** (main 101 = instant 503 structurally; sub 102 =
+perfect) + connection-slot exhaustion (reboot clears) — NOT a retry/flow bug.
+(2) **Blocker #1:** the camera never POSTed at all (0 alarms ever vs 1126 on the entry cam); its
+**Diagnose dump showed a CORRUPT config DB** (`Main Db is broken`/`db_restore failed`/`reset cfg`) —
+factory-reset fixed it.
+(3) Gateway/DNS was a **red herring** (working cam had none; broken cam had both).
+(4) **Blocker #2:** post-reset it pushed **plain `VMD` with no target** → backend gates on
+`target=="vehicle"` (`hikvision-alarm.ts` reads `<targetType>`/`<detectionTarget>`/`<objectType>`)
+→ ignored. Enabling the AcuSense **Vehicle target filter** made the push carry
+`<targetType>vehicle</targetType>` (confirmed live on a drive-through). "VMD/Motion" is the right
+event for this class — it's the *target filter* that matters.
+Flagged an **observability gap**: a camera with `alarmPushEnabled=true` and 0 pushes ever should be
+a surfaced status (cf. the reader-liveness fix). Recorded in the `g3h-anpr-push-gotchas` memory + a
+new troubleshooting section in [[lpr-camera]]. No code changed — diagnosis + camera reconfig only.