test: PostgreSQL integration test project (Testcontainers) for PostgreSQL-only code #277

Parent

#276

What to build

Code that only real PostgreSQL can exercise gets tested against real PostgreSQL. Today such code (ExecuteDelete/ExecuteUpdate, advisory locks) is excluded from mutation testing and never runs in a test. The work queue in #276 puts its correctness core (SKIP LOCKED claims, attempt fencing, partial unique indexes) in exactly that category.

This ticket adds a new integration test project that starts a PostgreSQL container through Testcontainers and applies the EF migrations. It covers the existing PostgreSQL-only members that have no tests today.

Acceptance criteria

• A new integration test project, named so that it is not matched by the *.Tests.Unit rule. It has its own SDK and package setup: xUnit v3, FluentAssertions, Testcontainers for PostgreSQL. Package versions live only in central package management.
• Each test run uses a fresh PostgreSQL container (same major version as the compose file), with the real migrations applied.
• Tests for the refresh-token repository's expired-token deletion: only expired rows are deleted, and the count returned matches.
• Tests for migrating under the advisory lock: two concurrent migrators both complete, and the schema is migrated exactly once.
• A CI job runs the project and is added to the CI gate's needs (never to branch protection). scripts/ci-gate.sh stays the rule.
• The project is outside the Stryker run, and mutation-guard.sh still passes.
• CLAUDE.md's Testing section says when a test belongs in the integration project instead of a unit test project.

First caller

The refresh-token expired-token deletion and MigrateWithAdvisoryLockAsync, both PostgreSQL-only and untested today. The work queue's store contract tests (next ticket) are the second caller.

Design

Decided with the maintainer on 2026-10-18 (#276, Testing Decisions: Testcontainers).