test(jobs): fix DB-subset pg pool exhaustion in jobs_stream SSE tests

[TaprootFreak]

Problem

The DB Subset Tests (M3 Ultra) CI job (ci:db label, narrow nextest selection, --test-threads 8) intermittently fails the five SSE tests with create: PoolTimedOut, each running >100 s before timing out:

• router::tests::jobs_endpoint_tests::jobs_stream_404_for_unknown_id
• router::tests::jobs_endpoint_tests::jobs_stream_closes_immediately_for_terminal_job
• router::tests::jobs_endpoint_tests::jobs_stream_emits_initial_phase_for_non_terminal_job
• router::tests::jobs_endpoint_tests::jobs_stream_failed_terminal_closes_with_complete_and_error
• router::tests::jobs_endpoint_tests::jobs_stream_forwards_dispatcher_phase_transition

The full coverage gate (same --test-threads 8, same SHA) keeps these tests green, so the tests themselves are sound.

Root cause

Migration-replay contention, not raw connection exhaustion. Every test that calls crate::test_db::setup_pool() creates a fresh per-test schema and replays the full migration suite (16 DDL files: tables, triggers, views) into the single shared postgres:17 container. Postgres serialises concurrent DDL on its system catalogs, so when the DB subset packs the migration-replaying tests together and eight run at once, each setup_pool() stretches from <1 s to tens of seconds.

The jobs_stream_* tests additionally hold their pool across deliberate sleep/timeout windows, so under that contention their connection acquisition exceeds the pool's 60 s acquire_timeout and surfaces as PoolTimedOut. The full coverage gate stays green because the same heavy tests are interleaved across the whole ~440-test suite rather than clustered in the narrow subset.

Local instrumentation confirmed peak server connections stay ~14/100 throughout — the bottleneck is DDL catalog locking, not the connection ceiling.

Fix

A workspace-root .config/nextest.toml test-group that caps the router::tests::jobs_endpoint_tests module at 2 concurrent threads. This bounds simultaneous migration replays for the heaviest module so connection acquisition stays well under the 60 s timeout, while keeping useful parallelism for the rest of the suite.

• Honoured by both cargo nextest run (the subset gates) and cargo llvm-cov nextest (the coverage gate).
• Carries no coverage semantics — the 100 % line/function gate is unaffected.
• Touches no test pool: the deliberately-narrow error-path dead_pool (max_connections(1) / 50 ms acquire_timeout) keeps exercising its PoolTimedOut arms verbatim.

How verified (local)

• Reproduced the contention: with the exact DB-subset selection from ci.yaml under --test-threads 8, the jobs_endpoint_tests ran ~34 s each (the slow path that tips into PoolTimedOut on the slower/noisier CI box).
• Subset green with fix, twice: 239/239 passed both runs, no PoolTimedOut; the jobs_stream_* tests dropped from ~34 s to ~15 s each.
• Coverage unchanged: the full gate (cargo llvm-cov nextest ... --fail-under-lines 100 --fail-under-functions 100 --test-threads 8) passes 442/442 at 100.00 % lines + 100.00 % functions.

Note: a hard PoolTimedOut failure was not reproduced on the local box (it passed at 8-wide, just slowly) — the local machine stays under the 60 s acquire_timeout that the busier CI runner crosses. The fix is validated by the green + much-faster subset runs and the unchanged coverage gate.