fix(#244,#245,#246): make concurrent + offline message delivery reliable

[TortoiseWolfe]

Summary

Fixes the messaging-reliability trio — #244, #245, #246 — the last three of the 10-bug GDPR/messaging Gap-Audit cluster. This PR closes the whole cluster (prior: #276+#277 security-critical, #278 GDPR trio).

They share one root — a non-atomic sequence-number trigger — and interact, so they ship together. A 3-agent adversarial design review reproduced the race on the live backend (12/30 concurrent inserts failed) and caught several defects in the initial designs, all fixed here.

The three fixes

#244 — Concurrent sends collide and get dropped

The assign_sequence_number() BEFORE-INSERT trigger did a non-atomic SELECT MAX(sequence_number)+1, so two concurrent inserts into one conversation got the same number and the loser hit unique_sequence (23505).

• A transaction-scoped advisory lock keyed on the conversation (pg_advisory_xact_lock(int4,int4) carved from the UUID) makes MAX+1 atomic per conversation.
• Verified live: 30 concurrent inserts → 0 collisions, sequence 1..30 gap-free (was 12/30 failing).

#245 — Offline messages delivered multiple times

The offline flush did a plain insert with no dedupe key, so every reconnect re-inserted a fresh row.

• Add messages.client_generated_id (the stable UUID the client already mints at enqueue) + a plain unique index (NULLs distinct, so live sends coexist; a partial index would break the ON CONFLICT inference — 42P10). Flush becomes upsert(onConflict, ignoreDuplicates) + .maybeSingle(), treating a null-no-error (DO NOTHING) as "already delivered."
• Verified live: replayed flush → exactly one row; NULL live sends not deduped.

#246 — Offline message lost on a transient conflict

The offline flush treated any error (incl. a transient 23505) as a permanent failure after 5 retries.

• Give it the live path's discrimination: a 23505 is retried in-loop with a fresh sequence read (rare now that Messages in a busy conversation are dropped under concurrent sends #244 is atomic — the belt-and-suspenders the review required); only a genuinely non-idempotent error defers to the next sync.
• The online send path is untouched and safe (never sets client_generated_id → stays NULL → excluded from dedupe → .single() never hits a skip).

Verification

• RLS DB-contract tests (tests/rls/messaging-reliability): Messages in a busy conversation are dropped under concurrent sends #244 gap-free under real concurrency (Promise.all of 25 inserts), Offline messages are delivered multiple times after reconnect #245 exactly-once + NULL coexistence — all live.
• Full 71-test RLS suite + 295 messaging/crypto unit tests green; type-check + lint clean.
• Schema applied live via the Management API (idempotent, monolithic migration). No edge-function changes.

🤖 Generated with Claude Code