feat(snapshot): re-encode captures + disk-pressure retention

Camera snapshots were stored RAW — the camera's full-res JPEG straight into
the BLOB, no resize/recompress. Measured on the dev DB: 300 snapshots = 81.7 MB
= ~72% of the 114 MB SQLite file (the big ones 2688×1520 / ~600 KB, Hikvision
main stream). They dominated the appliance's single backed-up DB file.

Re-encode on capture (snapshot.ts):
- Downscale each frame to SNAPSHOT_MAX_EDGE (1280px long edge) + recompress at
  SNAPSHOT_JPEG_QUALITY (80) via sharp (libvips, Apache-2.0) before storage —
  ~6-10× smaller (verified 2688×1520 → 1280×724, ~8×), plate still readable,
  clean image/jpeg (drops the camera's charset cruft). STORAGE-ONLY: recognition
  keeps the ORIGINAL full-res bytes (downscaling hurts OCR). Fail-soft — a
  re-encode error stores the original, never drops the snapshot or blocks the
  (already-open) path. sharp lives in apps/server (owns the capture path), where
  bcrypt already establishes the native-dep pattern.

Disk-pressure retention (snapshot-retention.ts) — a SAFETY VALVE, not the daily
mechanism (the re-encode does that). Daily check reads the DB filesystem used%
(statfs on db.$client.name); no-op unless ≥ SNAPSHOT_DISK_HIGH_PCT (70). Over the
mark: delete the OLDEST until an estimated SNAPSHOT_DISK_FREE_TARGET_PCT (10%) of
disk is freed — never below SNAPSHOT_MIN_KEEP (500) — then VACUUM once to return
space to the OS. A DELETE only frees SQLite pages (disk doesn't drop until VACUUM),
so the loop is driven by estimated freed bytes (SUM(length(bytes))), not a live
disk re-read; the prune owns the DB-locking VACUUM, run daily off-peak. diskUsage
is injectable for tests. None of this touches the signed ledger — snapshots are
unsigned/advisory, referenced only by id.

Tests: encodeForStorage (downscale / clean-type / no-enlarge / fail-soft) +
pruneSnapshots (no-op below mark / delete-oldest-to-target + VACUUM / MIN_KEEP
floor / skip-VACUUM-when-empty). All four snapshot env knobs documented in the
komodo env reference. Full workspace build/lint/test green; the prune smoke-verified
on a scratch DB copy (file shrank after VACUUM).

Existing ~81.7 MB of raw snapshots are unchanged (a one-off re-encode backfill is
a separate optional follow-up). Updated entry-exit-points + technology-stack wiki.

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

wiki/concepts/entry-exit-points.md

@@ -104,7 +104,27 @@ Captured **after** the barrier opens, **never awaited** — a camera failure can
 open (the signed ledger is the decision). Stored as a **BLOB in the `snapshots` table** (single
 backed-up DB, nothing scattered on disk), in its own table so hot telemetry scans don't drag image
 bytes and images prune independently. Linked to the signed `vehicle_entry/exit` by `identity`.
-Served read-only via `GET /api/snapshots/:id`. **Retention is unresolved** — see [[open-questions]].
+Served read-only via `GET /api/snapshots/:id`.
+
+**Re-encoded for storage (2026-06-28).** Cameras serve full-res JPEGs (a Hikvision main stream is
+2688×1520 / ~600 KB); stored raw, snapshots dominated the appliance DB (measured ~72%). Each frame
+is now **downscaled (long edge ≤ `SNAPSHOT_MAX_EDGE`=1280) + recompressed (`SNAPSHOT_JPEG_QUALITY`
+=80)** before storage via [[technology-stack|sharp]] (~6–10× smaller, plate still readable). The
+re-encode is **storage-only** — ANPR recognition runs on the **original full-res** bytes
+(downscaling hurts OCR). Fail-soft: a re-encode error stores the original, never drops the snapshot
+(`snapshot.ts` `encodeForStorage`).
+
+**Retention (2026-06-28, resolves the old open question) — DISK-PRESSURE safety valve.** Snapshots
+are unsigned/advisory, so they prune freely. The day-to-day shrink is the re-encode above; pruning is
+a backstop that only fires under real disk pressure. A **daily** check (`snapshot-retention.ts`
+`pruneSnapshots`, wired in `server.ts`) reads the DB filesystem's used%; if it's **≥
+`SNAPSHOT_DISK_HIGH_PCT`=70%** it deletes the **OLDEST** snapshots until an estimated
+`SNAPSHOT_DISK_FREE_TARGET_PCT`=10% of the disk is freed — never below the **`SNAPSHOT_MIN_KEEP`=500**
+floor — then **`VACUUM`s once** to return the space to the OS (a row delete only frees SQLite pages;
+the file doesn't shrink until VACUUM, which this prune now OWNS — daily, off-peak). Because a delete
+doesn't move disk-used% until the VACUUM, the loop is driven by **estimated freed bytes**
+(`SUM(length(bytes))` of deleted rows), not a live disk re-read. On a roomy booth disk this is a
+near-permanent no-op. (Replaced the first cut's age/row-cap model the same day.)
 
 ### Refused entry/exit ALSO snapshots (2026-06-19)
 A snapshot is evidence of **who was at the barrier** — which matters *most* when the barrier is