Add transient-DB resilience (EnableRetryOnFailure) on the request path #269

Deployment-readiness gap (#244), RECOMMENDED — flagged by 2 of 3 reviewers.

Problem

The HTTP request path has no resilience to transient DB failures. UseNpgsql is configured with no execution strategy — EnableRetryOnFailure appears nowhere (PostgresDbContextConfigurator.cs). The background worker was hardened against transient outages in #65 (DurableJobWorker.cs:41-71), but a request that hits a managed-Postgres restart/failover or a dropped pooled connection throws straight to a 500. /error only maps concurrency/serialization codes (Program.cs:751-772), not transient connection loss.

Fix

Enable a bounded Npgsql retry strategy (NpgsqlRetryingExecutionStrategy via EnableRetryOnFailure). Note the interaction: a retrying strategy disallows user-initiated transactions, so the export's explicit RepeatableRead transaction paths must move to dbContext.Database.CreateExecutionStrategy().ExecuteAsync(...). Use the existing idempotency keys to keep ambiguous commit/retry safe.

Verify

Kill the DB mid-request on a dev instance — observe the request retry and succeed (or fail cleanly) instead of an unhandled 500; the export transaction still runs under the strategy.

Part of the #244 deployment-readiness audit; tracked in epic #15.