fix(worker): pg_durable_worker hangs on graceful PostgreSQL shutdown

[Copilot]

pg_durable_worker could survive pg_ctl stop -m fast, keeping the postmaster alive until the stop timeout, blocking restarts and leaving a stale postmaster.pid. The stuck process was observed in futex_wait_queue (Tokio blocking pool waiting on SQLx reconnection) and do_epoll_wait (Tokio I/O reactor still polling dying connections).

worker.rs — shutdown correctness

• Explicit pool close: The duroxide store's PgPool (min_connections=1) was never awaited on close — only dropped — leaving its maintenance task spinning. Now closed with a 5 s timeout after duroxide shutdown completes.
• Bounded pool close: mgmt_pool.close() and poll_pool.close() are now wrapped in tokio::time::timeout(5s) so a non-responsive backend can't block indefinitely.
• Duroxide shutdown delay: Runtime::shutdown(Some(10_000)) unconditionally sleeps 10 s before aborting tasks. Reduced to 2 s — pending work errors out anyway once PG backends are gone.
• Interruptible retry sleeps: All bare tokio::time::sleep() calls in retry/polling loops replaced with tokio::select! via a new wait_for_shutdown() helper, so shutdown is noticed within ~100 ms rather than waiting out the full sleep.
• Tokio runtime shutdown: Changed rt.shutdown_timeout(5s) → rt.shutdown_background() — all async cleanup is now done inside block_on; residual blocking threads are killed by proc_exit() on BGW exit.

// Before: pool just dropped, maintenance task keeps running
drop(duroxide_runtime);

// After: explicit close with timeout
let _ = tokio::time::timeout(
    Duration::from_secs(5),
    duroxide_store.pool().close(),
).await;

Scripts — stop resilience

• pg-stop.sh, test-e2e-local.sh, test-upgrade.sh: stop -m fast now uses -t 30; if it times out the scripts fall back to -m immediate automatically instead of masking the failure with || true.

New: scripts/test-shutdown.sh

Regression harness for this class of bug. Exercises three scenarios: worker idle at shutdown, worker mid-execution, and rapid stop/start cycles — each asserting the server stops within a configurable timeout (default 20 s).

• Fixes Graceful PostgreSQL shutdown can hang pg_durable_worker and block restart #308