Add native Postgres multi-session coverage for dispatch admission

[ncolesummers]

Summary

PR #100 added durable dispatch admission with a persistent group-guard row selected FOR UPDATE, plus PGlite integration coverage for capacity deferral and issue exclusivity. PGlite validates the SQL, transactions, and persisted invariants, but its embedded execution model cannot prove real PostgreSQL lock waiting across independent sessions.

Add a native PostgreSQL integration lane that deterministically overlaps dispatch transactions and proves the production concurrency contract.

Why this belongs in M3

This is the remaining verification boundary for the durable-loop admission behavior delivered by #96 and PR #100. It is not general test-harness cleanup: M3 should not close without direct evidence that the database lock used to enforce maxInFlight behaves correctly under real multi-session contention.

The existing seeded-postgres-e2e CI job already provisions PostgreSQL 17 and is the preferred infrastructure to extend or reuse.

Scope

• Exercise the real dispatch APIs against two independent PostgreSQL connections/sessions sharing one migrated test database.
• Add a deterministic synchronization seam or barrier that holds the first admission after it acquires the group guard and before it commits.
• Do not use wall-clock sleeps, retry loops, PGlite, or repeated probabilistic stress runs as substitutes for observable transaction overlap.
• Keep the seam test-only or narrowly injected; do not refactor unrelated dispatch behavior.
• Preserve the existing local-database safety rules and fail clearly when the native PostgreSQL lane is unavailable.
• No rendered UI behavior changes are expected.

Acceptance criteria

• Tests are written first and the initial red state shows that the existing PGlite suite cannot establish native multi-session lock scheduling.
• The test uses two independently verifiable PostgreSQL sessions, not two wrappers over one connection.
• With one resolved group and maxInFlight: 1, two overlapping dispatches for distinct issues produce exactly one dispatched run with one acquired lease and one deferred queued run without a lease.
• The losing transaction cannot pass the guarded capacity check while the winning transaction still holds the group-guard lock; it completes only after the winner commits.
• Concurrent attempts for the same repository issue across development and research admission remain exclusive: exactly one nonterminal run owns the issue, and the loser observes contention without an unhandled uniqueness error.
• Persisted evidence is asserted after both transactions settle: active-run count, acquired-lease count, run outcome, and queue state all match the manifest cap.
• The native PostgreSQL command runs in CI against the existing PostgreSQL 17 service and fails closed rather than skipping or falling back to PGlite.
• Local run instructions name the exact command and required safe DATABASE_URL; test cleanup cannot target a production database.
• Focused native-PostgreSQL checks and bun run validate pass before review.

Non-goals

• Changing dispatch, lease, or retry semantics unless the native test exposes a real defect.
• Folding this into Harden PGlite integration test harness and migration replay performance #40, which covers the PGlite harness rather than PostgreSQL session scheduling.
• Folding this into Wire Neon Postgres into Vercel production and preview deployments #70 or Add local Postgres bootstrap and diagnostics for native macOS development #80, which own hosted wiring and local bootstrap respectively.
• Adding browser, responsive, accessibility, or screenshot cases for this backend-only invariant.

References

• Refs Enforce manifest concurrency, dispatch leases, and retry backoff #96
• Refs feat(loops): enforce durable dispatch leases and retry backoff #100
• Refs Harden PGlite integration test harness and migration replay performance #40
• Refs Wire Neon Postgres into Vercel production and preview deployments #70
• Refs Add local Postgres bootstrap and diagnostics for native macOS development #80
• Refs ADR 0017