test(graph-maintenance): reproduce concurrent-insert deadlock on the queue

[nicoloboschi]

Summary

A deterministic, DB-level regression guard for the concurrent-insert deadlock fixed in #2353.

#2353's own tests only assert that the Python list handed to conn.execute is sorted — they never exercise a real lock or prove a deadlock is prevented (and would spuriously fail a refactor to sort in SQL). This adds the behavioural test:

• test_unordered_concurrent_enqueue_deadlocks — two concurrent transactions insert overlapping graph_maintenance_queue keys in opposite order, with an asyncio.Barrier between the two per-row unique-key locks so the cross-wait is guaranteed. Postgres detects the cycle and aborts one with DeadlockDetectedError (call takes ~1s = deadlock_timeout).
• test_ordered_concurrent_enqueue_does_not_deadlock — same setup, both in sorted order (what fix(graph-maintenance): sort unit_ids to eliminate concurrent-insert deadlock #2353 produces): no cycle, both sets land in the queue.

Modelling note

Production enqueues a whole victim set in one INSERT ... SELECT unnest(...) ON CONFLICT DO NOTHING statement. That single statement still takes the per-row unique-key locks one at a time in unnest order — we just can't pause inside a statement, so each worker issues the rows one at a time with a barrier between. Same lock, made observable.

Notes

• Runs against the real Postgres test DB via the existing memory fixture (like test_graph_maintenance.py); uses a unique bank_id per test, so it's isolated under xdist.
• No production code changes.