fix(sqlite): serialize management store writes through the engine write lock

[LeeroyHannigan]

What

Routes every management and credential-plane write in the SQLite backend through the engine's existing write_lock, so the two connection pools that open the same database file never contend for the SQLite file write lock.

• SqliteCatalogStore::with_encryption_key takes the engine's Arc<Mutex<()>>; the server wiring in lib.rs passes the one instance the engine already uses, so engine writers and management writers queue on a single lock.
• A lock_writes() helper acquires it. Every write statement or transaction in the catalog store (set_setting, metrics insert and prune, failed-login bookkeeping), the admin store, and the management stores (users, access keys, policies, groups, roles, accounts, sessions) takes the lock before the statement or begin and releases it with the statement. Reads never take it.
• The credential store has no write statements and is unchanged. The GSI propagation worker already held the lock.
• The out-of-process CLI constructors (settings, doctor) keep a fresh lock, since no engine exists in that process.
• The store.rs module doc now lists init-time bootstrap as the only deliberate exclusion from the lock.
• Seven new tests in d1_write_lock_tests, one per store family, each proving the write blocks while the engine lock is held and completes after release, using the assert_serialized harness introduced by fix(sqlite): serialize all writers through the engine write lock #321.

Why

run-integration-sqlite fails intermittently with one test out of about 980 returning HTTP 500 where 204 was expected. Three occurrences this week, all the same assertion in tests/test_auth_integration.py::TestIBAC::test_readonly_user_denied_write on put_user_policy:

• run 34507896936 (merge group for fix(mongodb): clean up account, index, and tag lifecycle data #309, 2026-09-10 17:23 UTC)
• run 34518061214 (fix(backup): report point-in-time recovery as unsupported #335, 2026-09-10 19:03 UTC)
• one more on a private mirror at the same commit lineage, where the identical commit passed on re-run

The server journal from the failed run names the cause at the same second:

ERROR extenddb_storage_sqlite::management_store::policies: put_policy: error returned from database: (code: 5) database is locked
ERROR extenddb_storage_sqlite::workers: GSI propagation worker: batch error: Internal error: error returned from database: (code: 5) database is locked

SQLite permits one writer per file. The engine serializes its writers with the in-process write_lock (design decision D1 in store.rs), and #321 moved every remaining engine writer inside it after measuring this same failure in August. It left the management stores outside and said so in the module doc: they write through the second sqlx pool in lib.rs, which for a file-backed database opens the same file, as plain autocommit statements with no lock. When such a write arrives while another connection has held the file write lock past the 5 second busy_timeout, SQLite returns SQLITE_BUSY and the management handler maps it to 500. The integration suite runs pytest with parallel workers against one server, so management writes from one worker overlap data-plane writes from another, which is the window.

Both upstream occurrences postdate #321, and neither PR they failed on touches the SQLite backend or the management store.

Testing done

Unit and lint gates on the branch:

cargo fmt --all -- --check                      clean
cargo clippy --all-targets -- -D warnings       clean
cargo test -p extenddb-storage-sqlite           80 passed, 0 failed, 1 ignored (13 d1_write_lock_tests, 7 new)
cargo test --workspace                          1183 passed, 0 failed

Failing-first check: with the lock call removed from put_policy, management_put_policy_waits_for_the_write_lock fails; restored, it passes.

Integration, reproducing the CI job locally (release build with --features sqlite, extenddb init --backend sqlite, serve --foreground --write-pid-file, then the CI invocation devtools/run-tests --extenddb --pytest --comprehensive --parallel --filter "not import_export"):

pytest suite            941 passed, 17 skipped, 1 xfailed  (plus 43 passed on a rerun of three files whose
                        first pass failed only from local CA-bundle and cwd differences; 984 distinct tests green)
comprehensive suite     331 passed
tests/test_auth_integration.py, three consecutive parallel runs   15 passed, 15 passed, 15 passed
server log             0 occurrences of "database is locked" across all runs

tests/test_gsi_async_queue_sqlite.py emits five "extenddb stop did not exit within 30s" warnings; the same file against a main-built binary emits the same five in the same 274 seconds, so that is existing harness behavior and not introduced here.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed
• Breaking changes are noted below (if any)
• If this changes the wire protocol, Storage trait, auth model, on-disk
  format, or public CLI surface, an RFC has been accepted or is linked
  below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a. Applies the existing design decision D1 recorded in the store.rs module doc (every SQLite writer holds the engine write lock) to the writers #321 left outside it. No wire, trait, auth, on-disk, or CLI change.

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.