docs: lock-line persistence unblocks the staleness audit (migration 033, lock_lines)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VsztNChZ7vEvSR61AuMhD1

specs/STATE.md

@@ -61,6 +61,19 @@
 > thin n; Phase-2 lock-staleness check BLOCKED (no multi-book retained AT LOCK — `bookprices`
 > is Redis current-only); pinnacle sharp ref only n=8 (+3.17pt, hint). Fix that would
 > strengthen it (NOT built): retain multi-book at lock + accrue sample. Promotion HELD.
+
+> ## 🔓 LOCK-LINE PERSISTENCE shipped 2026-07-29 (commit c7067c8): unblocks the staleness audit
+> The audit's BLOCKED check (was our locked line stale-high vs consensus AT LOCK?) is now
+> being unblocked. New `lock_lines` table (migration 033, applied+tracked) — the lock-time
+> analog of `closing_captures`. `lockLineCapture.buildLockRows` persists each graded prop's
+> per-book lines (both odds + a lock timestamp) from the in-memory `props` at the lock
+> moment (`ts`, no Redis re-read → no TTL race), in `snapshotService` right after
+> `enriched`. FENCED: RLS-no-policies (service-role only) + a grep test — read by nothing on
+> the grade path; grade byte-identical proven (runSnapshot grades identical with persist
+> on/off). **Accrues FUTURE rows only — does NOT retroactively fix the existing 62; the
+> confirming audit still needs weeks of settled lock+close+outcome rows.** Volume ~1.5-3k
+> rows/day. Populates on the next snapshot tick (14:00 UTC); no promotion, no served edge,
+> no capture-of-close change. Next: let it accrue, then re-run the staleness audit.
 - **Redirect EXISTS + WIRED:** `closingCapture.buildCaptureRows`→`closing_captures` (append-only,
   provenance: captured_at/book/line_type/both-prices/missed_reason) via `intradayRefreshService:221`
   + internal endpoint; `ledgerService.attachClosingProb`→`closing_prob` (de-vigs both raw sides,