fix(worker): serialise consolidation claims per bank within a batch (#3700) (#3764)

Consolidation was kept to one run per bank only by excluding banks that
already had a *processing* row. That is no guarantee at claim time: with
several pending rows and nothing yet processing — the state every recovery
path produces (`_reclaim_own_processing_tasks` returns all of a worker's
processing rows to pending in one statement, plus `_schedule_retry` /
`_defer_operation` / `hindsight-admin recover`) — a single batch claimed
them all. Both runs then read the same backlog and handed the same
memories to the LLM, doubling inference on the slowest path in the system.

graph_maintenance got a predicate for exactly this in #3230. Generalise it:
`bank_serialization_sql` now covers both operation types, matching peers on
the candidate's own operation_type, and every consolidation claim query
(plain, and both bank-priority tiers) carries it. Its older-pending branch
is what bounds a batch to one row per bank, and it also closes the window
where a peer is claimed but not yet committed as processing, which the
separate busy-bank query could not see. That query and its `bank_id !=
ALL(busy)` filters are now redundant and are gone.

Scoped consolidations need no carve-out: claim-time suppression defers,
where submit-time dedup drops, so a scoped run queues behind the bank's
in-flight one and is claimed later with a fresh watermark.