Drop lock_lines and retire its writer (dead table, dead writer)

lock_lines was built in Session 64 for a staleness audit - join lock-time
per-book lines to closing_captures and ask whether our locked line was
stale-high vs consensus. That audit was never written. ruler-comparison.sql
records why: only 43 settled rows ever joined it with >=2 two-sided books.

Measured before removal: 367,595 rows, 104 MB, zero readers in src/, scripts/
or web/src/ - the only from('lock_lines') was an upsert, every other mention a
comment. Zero dependents: no FK, no view, no trigger. The newest pg_dump held
all 367,595 rows, pg_restore-verified before the drop.

The write is off too, because a dead table that keeps refilling is only half
solved: it was accruing 36,440 rows/day, 10.3 MB/day, 23% of all database
growth, for a question nobody was asking. buildLockRows is kept and still
tested - the logic was never what was wrong, and re-arming is one flag plus
re-creating the table.

DB 510 MB -> 406 MB: 81% of the 500 MB cap, +94 MB headroom, under it for the
first time in months.

Moat and grade untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -2141,6 +2141,28 @@ phased plan in the Session-57 conversation / BUILD-STATE Next section).
   historical 4,236,398 rows are now STATIC — the cleanup can be scheduled
   calmly instead of raced, and it no longer regrows after a delete.
 
+## Reclaim 2 — lock_lines dropped + writer retired (non-obvious)
+- **`lock_lines` IS GONE (2026-08-12).** 367,595 rows / 104 MB, **zero readers**
+  in `src/`, `scripts/` or `web/src/` — the only `from('lock_lines')` was an
+  `.upsert`, everything else was a comment. It was built (S64) for a staleness
+  audit — join lock-time per-book lines to `closing_captures` — **that was never
+  written**; `scripts/ruler-comparison.sql:17` records why (only 43 settled rows
+  ever joined it with >=2 two-sided books).
+- **THE WRITE IS OFF TOO.** A dead table that keeps refilling is half-solved: it
+  was accruing **36,440 rows/day = 10.3 MB/day = 23% of ALL database growth**.
+  `lockLineCapture.persist()` now returns `{retired:true}` without touching a
+  client. Re-arm with `LOCK_LINE_CAPTURE=1` — which ALSO requires re-creating the
+  table (migration 033); the pg_dump chain holds the history.
+- **`buildLockRows` is KEPT and still tested.** The logic was never what was
+  wrong — it is pure and correct, and the capture is one flag away if anyone
+  writes the audit. Retiring a writer is not the same as deleting the capability.
+- **`retired` and `no supabase env` must read differently in the log** — one is a
+  decision, the other is a fault. The call site distinguishes them; a test asserts it.
+- **DB: 510 MB → 406 MB (102% → 81% of cap, +94 MB headroom).** First time under
+  the free-tier cap in months. Growth drops ~45 → ~35 MB/day.
+- Safety net was exact: the newest pg_dump held **367,595 lock_lines rows —
+  matching the live count row-for-row**, pg_restore-verified before the drop.
+
 ## Active Skills
 - vyndr-voice (all user-facing output)
 - prop-analysis (grading methodology)