feat(fp): WP-22 — durable persistence (SQLite/EF Core)

Applications, documents (+ audit log) and the brief move off static in-memory
Dictionaries onto a real SQLite file via EF Core, so demo data survives a
process restart or `docker compose restart api` for the first time. The three
stores (ApplicationStore/DocumentStore/BriefStore) keep their exact public
signatures and static-class shape — no DI, no async ripple into Program.cs's
minimal-API handlers — each method just opens a short-lived AppDbContext via
Db.Create() under the same lock it already had. Opaque nested shapes (a
wizard's draft snapshot, a brief's sections/placeholders/status) are stored as
JSON text columns rather than redesigned into relational tables, matching the
existing "don't interpret it" posture.

Found two things the WP's own text got wrong, corrected in
docs/backlog/WP-22-durable-persistence.md's Deviations section: SeedData never
seeded these three stores (only the read-only BRP/DUO-mimicking GETs, which
stay in-memory) so there's no seed step; and no new docker-compose volume is
needed since the existing bind mount already covers the SQLite file — verified
against this environment's real podman-backed compose stack, not just by
reading the file.

Also: pinned SQLitePCLRaw.bundle_e_sqlite3 to 3.0.3 (EF Core Sqlite's own
transitive default bundles a pre-3.50.2 SQLite with a known high-severity
memory-corruption advisory); found and fixed a real xUnit test race where
concurrent test-class hosts stomped a shared static connection-string field,
fixed by disabling cross-class test parallelization rather than adding DI the
stores don't otherwise need.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

backend/tests/BigRegister.Tests/TestWebApplicationFactory.cs

@@ -0,0 +1,41 @@
+using Microsoft.AspNetCore.Hosting;
+using Microsoft.AspNetCore.Mvc.Testing;
+
+// WP-22's stores read a single static Db.ConnectionString (there's no DI, matching
+// their pre-WP-22 static-Dictionary shape — see Data/Db.cs). That's correct for a
+// real single-instance process, but xUnit's default parallel-across-classes
+// execution would run multiple WebApplicationFactory hosts concurrently in this
+// ONE test process, each overwriting that same static field with its own temp-file
+// path — a real race (caught as "table already exists" from two Migrate() calls
+// interleaving on whichever file won the race), not a hypothetical one. Serializing
+// test classes is the fix, not a redesign of the stores for a test-only concern.
+[assembly: CollectionBehavior(DisableTestParallelization = true)]
+
+namespace BigRegister.Tests;
+
+/// <summary>
+/// WP-22 moved Applications/Documents/Briefs off in-memory dictionaries onto a real
+/// SQLite file (see Data/Db.cs). Unlike static dictionaries, a shared file path
+/// would let concurrent test classes' WebApplicationFactory instances hit the same
+/// file at once — xUnit runs different test classes in parallel by default, and
+/// SQLite tolerates only one writer at a time, so that's a real "database is
+/// locked" flake risk, not a hypothetical one. Every test class below points at its
+/// own throwaway file instead, deleted when the factory (and its class's tests) are
+/// done — the same one-store-per-class isolation the old dictionaries gave for free.
+/// </summary>
+public sealed class TestWebApplicationFactory : WebApplicationFactory<Program>
+{
+  private readonly string _dbPath = Path.Combine(Path.GetTempPath(), $"bigregister-test-{Guid.NewGuid():N}.db");
+
+  protected override void ConfigureWebHost(IWebHostBuilder builder) =>
+      builder.UseSetting("ConnectionStrings:AppDb", $"Data Source={_dbPath}");
+
+  protected override void Dispose(bool disposing)
+  {
+    base.Dispose(disposing);
+    if (!disposing) return;
+    File.Delete(_dbPath);
+    File.Delete(_dbPath + "-shm"); // ponytail: best-effort — WAL sidecar files if SQLite created any.
+    File.Delete(_dbPath + "-wal");
+  }
+}