test: close backup snapshot fixture SQLite connections explicitly #209

What happened

Stability audit finding F10 / P3 (2026-09-27). Priority is an audit recommendation, not a claim of a production incident.

The backup snapshot tests use with sqlite3.connect(...) as if it closed the connection. It controls transaction commit/rollback but does not close the connection.

The Python 3.14.7 full-suite audit produced five unclosed-database ResourceWarnings. A targeted tracemalloc run identified these fixture allocation sites. This evidence is test-only and does not establish a runtime database leak.

What you expected

Close fixture-owned connections explicitly, for example with contextlib.closing plus the existing transaction context, while retaining the test's transaction semantics.

Environment

• Baseline: published session-peer v1.0.1, commit 55168c3bea5a49e81916fdead57d3634def6b1d6.
• Reproduction: isolated source/tag fixtures; no live message/ACK tests or production mutation.
• Audit environments: macOS arm64, Python 3.14.7; Control tests use Node 22.14.0. Linux evidence is explicitly identified above where applicable.
• Discovery output: not applicable to this fixture; no real session identifiers or credentials are included.

Source evidence

• tests/control_integration/test_control_backup_snapshot.py#L32
• tests/control_integration/test_control_backup_snapshot.py#L92

Acceptance criteria

• Close connections on both passing and failing fixture paths.
• Run the affected suite with ResourceWarning surfaced as a failure and capture unraisable/finalizer warnings where necessary.
• Verify snapshot/restore assertions remain unchanged and no runtime changes are required.

Scope and limitations

Reference: https://docs.python.org/3/library/sqlite3.html#how-to-use-the-connection-context-manager . Earlier campaign notes mentioned this warning; no duplicate tracking issue was found.

Target: v1.0.2 stability work. This issue does not authorize a release or operating-service changes. Offline reproduction establishes the failure mechanism, not attribution of historical #161 incidents.

Checked

• Searched existing issues for duplicates.
• Removed credentials, conversation contents, private paths and real device/session identifiers.
• Used isolated fixtures without weakening inbound permissions.