v0.1.67 — scanRows logs corrupt JSON instead of discarding it

DLP/capture-M4 — silently discarded JSON corruption in admin capture views

scanRows is shared by every admin-facing capture view (List, Get, ReviewQueue) and silently discarded any json.Unmarshal failure on all three JSON columns (detected, secondpass_labels, gold_labels). Its sibling PendingForSecondPass handles the identical corruption on the same detected column by at least logging a warning. Since these columns are jsonb (Postgres validates JSON syntax at write time), the realistic failure mode isn't invalid syntax — it's valid JSON in the wrong shape for []dlp.Finding (a stray object instead of an array, from a future encoding bug or a hand-edited row). Before this fix, that would render as a silently-empty finding/label list in the admin UI with zero diagnostic trail.

Fix: scanRows now logs the same "capture: corrupt <column> JSON" warning PendingForSecondPass already does, naming the column and the row id, for all three columns.

Test plan:

• TestScanRowsLogsCorruptJSON (real Postgres): seeds a row, directly UPDATEs secondpass_labels to a syntactically-valid-but-wrong-shape JSON value, calls the real Get, confirms it still succeeds and that a warning naming both the corruption and the row's id was logged
• Verified load-bearing via surgical revert — genuinely failed (no log output); reverted before committing
• Full gate green: gofmt, go build, go vet, full test suite

PRs: #135 (fix), #137 (chart bump — skips 0.1.66, already claimed by another in-flight PR on this repo)

Thirty-ninth of 62 confirmed findings — closes DLP/capture's last Minor finding. DLP/capture subsystem is now fully closed: every Critical, Important, and Minor finding fixed. Next up: re-deriving Protocol translation's uncatalogued Minor findings from current code.

🤖 Generated with Claude Code