Pending ladder: the sweep and the record lock their rows in key order

discardKeys updated with `release_key = ANY(subquery)`, which locks rows in
the plan's scan order, and deadlocked against a batch upsert that takes its
rows by key (LOG.md (137)). It now updates from a subquery that selects the
rows ORDER BY release_key FOR UPDATE, so the locks are taken sorted (the
plan: LockRows above Sort). record() runs the same SELECT ... FOR UPDATE over
its taken rows before its UPDATE ... FROM jsonb_to_recordset, whose join
order the planner chooses.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

REBUILD.md

@@ -950,9 +950,12 @@ f. **Nothing enters the catalog without a usable name** (amended
    climb, each by an index (`pending_releases_signature_idx` for a
    poster's rows: tested on the rows, a signature was a scan of the whole
    table; LOG.md (133), (134)). The batch store, the record, the claim
-   and the sweep lock pending rows in one order (`lockOrder`), and a
-   flush that deadlocks anyway keeps its outcomes for the next (LOG.md
-   (134)). The namer
+   and the sweep lock pending rows in one order, by key and the counters
+   after (`lockOrder` for the multi-row statements; the record and the
+   sweep lock their rows with `SELECT … ORDER BY release_key FOR UPDATE`
+   first, since an UPDATE's join or `= ANY(subquery)` locks in plan
+   order), and a flush that deadlocks anyway keeps its outcomes for the
+   next (LOG.md (134), (137)). The namer
    (`app/services/pending_namer.ts`, in the prober's process): a named
    release's article span read again from the corpus (the stored range's
    chunks) or by XOVER on a connection of its own, a chunk of articles