vfs: fix Windows WAL corruption by mapping the wal-index into wasm memory

[franchb]

Fixes #404.

Problem

On Windows (and in the sqlite3_dotlk build), concurrent WAL writes across pooled connections — a single *sql.DB with SetMaxOpenConns(N>1) and ordinary BEGIN DEFERRED writers — corrupt the database, and produce SQLITE_PROTOCOL / database is locked error storms under load.

The root cause is the WAL-index copy scheme (vfs/shm_copy.go). The WAL-index is kept in a per-connection private copy and synchronized with the shared -shm file only at xShmLock boundaries. But wal.c reads and writes the WAL-index between lock calls and relies on seeing other connections' updates live:

• readers re-read the two header copies around a barrier and retry on a dirty read (walIndexTryHdr);
• walTryBeginRead re-checks aReadMark[] and the header after taking a read lock and retries on any change;
• the checkpointer, when its exclusive probe of a reader slot loses to a live reader, caps mxSafeFrame on the aReadMark value it just read (walCheckpoint).

Copy-at-lock-boundary is too coarse for those patterns, so a connection acts on a stale view. Under concurrent writers this lets a checkpointer backfill stale page versions into the database and truncate frames that were never backfilled — corrupting the file. I confirmed this with word-level instrumentation of the private/shared/shadow copies and a content trace of the data plane (the checkpointer demonstrably writes older committed page versions to the main DB).

This is Windows-only among the VFS shapes (the unix build maps -shm into wasm memory directly; native C shares one mapping), and it reproduces on every released version back to when the Windows shared memory was introduced.

Fix

Stop copying. On Windows 10 1803+ / Server 2019+, map the -shm regions directly into the wasm linear memory using address-space placeholders (VirtualAlloc2(MEM_RESERVE_PLACEHOLDERS) + MapViewOfFile3(MEM_REPLACE_PLACEHOLDER)) — the analogue of the MAP_FIXED mapping the unix build already uses. SQLite then works on genuinely shared, always-current memory; xShmBarrier becomes a plain fence, and the private/shadow copies and their synchronization points disappear. This removes the entire staleness class by construction — both the corruption and the SQLITE_PROTOCOL storms.

The wasm heap is committed at 64K (allocation-granularity) so a 64K-aligned WAL-index view never straddles two allocations, which a placeholder split cannot cross.

On older Windows the copy scheme remains as a fallback, now with process-wide copy serialization and exact per-page comparison (instead of the header-equality fast path, which is unsound: SQLite changes hash-table words while leaving the 136-byte header byte-identical, e.g. walCleanupHash after a rollback). This makes the fallback less bad, though it cannot be made fully correct — see the caveat below.

What changed

• internal/sqlite3_wrap/placeholder_windows.go (new): thin bindings for VirtualAlloc2 / MapViewOfFile3 / UnmapViewOfFile2 and a capability probe.
• internal/sqlite3_wrap/mem_windows.go: reserve the wasm memory with placeholders; MapFileRegion / UnmapFileRegion map file views into carved holes.
• vfs/shm_windows.go: dual path — direct-map on 1803+, copy scheme as fallback.
• vfs/shm_copy.go, vfs/shm_dotlk.go: copy-scheme hardening for the fallback path.
• vfs/tests/wal_stress_test.go (new): a heavy concurrent-WAL-writers regression test (short-mode skipped; excluded from sqlite3_dotlk).

Validation

• The standalone reproducer from Windows: concurrent WAL writes across pooled connections corrupt the database #404 is clean 10/10 on Windows Server 2022 (stock corrupts on ~every run); at 2× concurrency it degrades only to a genuine busy-timeout with the database intact.
• The regression test passes on Windows and Linux.
• Cross-process interop: the fixed writer and a native sqlite3.exe (stock 3.53.2) reading the same WAL database concurrently — PRAGMA integrity_check = ok, foreign_key_check clean, 128000 rows consistent, no read errors. Lock offsets and the on-disk format are unchanged, so native tools stay compatible.
• -race is clean with the fix.

Caveats / open questions

• Full correctness requires Windows 10 1803+ / Server 2019+ (for the placeholder APIs). Older Windows uses the improved-but-imperfect copy fallback; I kept it because I did not want to drop support, but I'd understand if you'd rather gate WAL differently there.
• The direct-map path serializes WAL-index copies only within a process (there are none — it's genuinely shared). But if you consider the copy scheme fundamentally, its cross-process Go↔Go story has the same class of issue; the direct map avoids it entirely on supported Windows.
• Happy to adjust the structure (e.g. how the Memory placeholder logic is factored, or the capability gate) to your taste.

[ncruces]

I've made this a bit harder to merge, because I committed my non fixes (because they cleaned up some deprecations, mostly). Sorry about that.

If it's not too much trouble to fix the conflict, as you drop the old Windows fallback, I'd appreciate it.

Otherwise, if it's too much of a bother, I can always merge this to a branch and take over.