test(api): isolate container DB between tests

[escape0707]

Summary

Part of #32454 (comment).

This is a diagnostic draft PR. It is expected to expose existing DB session leaks before the service fixes are applied.

The code change is the intended test infrastructure direction: after each container integration test that used the containerized Flask app, reset SQLAlchemy application tables with TRUNCATE ... RESTART IDENTITY CASCADE.

The cleanup also sets SET LOCAL lock_timeout = '5s' for the cleanup transaction. That is test-only behavior in conftest.py: if another session is holding a conflicting lock, CI should fail loudly instead of hanging for a long time.

Why this exists

Container integration tests currently share one PostgreSQL container and many tests/services commit through different sessions. Without a central cleanup contract, DB state can leak between tests unless each test adds its own local cleanup workaround.

This draft PR records what happens when central DB isolation is enabled before fixing the existing session leaks. The follow-up service PR should close the leaked private sessions, and the final DB isolation PR should build on that.

Validation

• uv run --project api ruff check api/tests/test_containers_integration_tests/conftest.py

[github-actions]

Pyrefly Type Coverage

Metric	Base	PR	Delta
Type coverage	0.00%	43.69%	+43.69%
Strict coverage	0.00%	43.22%	+43.22%
Typed symbols	0	22,136	+22,136
Untyped symbols	0	28,840	+28,840
Modules	0	2558	+2,558

[escape0707]

Diagnostic result recorded.

This draft PR proved the intended failure mode: enabling central container DB cleanup before the service session fixes makes API Integration Tests fail loudly during cleanup instead of hanging.

Evidence from CI:

ERROR api/tests/test_containers_integration_tests/services/test_attachment_service.py::TestAttachmentService::test_should_return_base64_when_file_exists - sqlalchemy.exc.OperationalError: (psycopg2.errors.LockNotAvailable) canceling statement due to lock timeout
[SQL: TRUNCATE TABLE ... upload_files ... RESTART IDENTITY CASCADE]

The job completed with 2409 passed, 8 skipped, 2 errors, so this was not a setup failure. The errors were the expected leaked-session/cleanup-lock signal.

Follow-up PRs:

• Service session fixes: fix(api): close base64 file lookup sessions #36308
• Final DB isolation PR after those fixes: test(api): isolate container DB between tests #36310