fix(sqlite): make startup-owned stores safe for FastAPI worker threads

[seonghobae]

Summary

Fixes a production-only failure mode in the standalone account-unification service. FastAPI builds the SQLite config and audit objects during application startup, then executes synchronous route handlers in worker threads. Python's default SQLite connection rejects that cross-thread use, so runtime federation/config mutations and merge audit writes can fail with sqlite3.ProgrammingError even though unit tests using in-memory fakes pass.

Changes

• enable deliberate cross-thread use for SqliteKvStore and SqliteAuditSink;
• serialize each shared connection with a re-entrant lock so transactions cannot interleave;
• configure a five-second SQLite busy timeout;
• preserve in-memory database support and existing close semantics;
• add worker-thread regression tests for both config and audit persistence.

Verification required

• uv run pytest -q
• uv run ruff check app tests tools
• uv run interrogate . at 100%
• Semgrep, CodeQL, security scan, and central coverage evidence

This is a prerequisite for the runtime federation registry in #18 and materially improves standalone reliability under real FastAPI request execution.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 50 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 7b123aa5-7adf-4acc-ad16-72ccc03e1eae

📥 Commits

Reviewing files that changed from the base of the PR and between 4e2cf58 and fa75f55.

📒 Files selected for processing (4)

• services/account_unification/app/audit.py
• services/account_unification/app/kv_store.py
• services/account_unification/tests/test_audit.py
• services/account_unification/tests/test_config.py

---

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Superseded by #42. The integration PR carries the SQLite worker-thread safety changes together with the federation API that exercises KvStore.delete, resource lifecycle cleanup, storage concurrency regression coverage, and the overlapping Keycloak 26/SCIM changes.