fix(wal): recover a connection that has fallen behind more than one WAL generation

[darshanp40]

Fixes #345.

The bug

#skipTx only ever accepted a broadcast whose WAL file generation (salt1) was exactly one ahead of the connection's own — #followFileChange checks salt1 + 1 and nothing else. A connection more than one swap behind throws invalid WAL file.

That alone would be recoverable, except #advanceTxId deletes the transaction from #mapIdToPendingTx before #skipTx can throw. Once it does, the id is gone for good — nothing else ever re-adds a given id once its broadcast has been seen — so #txId can never advance past it. Every later broadcast then falls through to #readTx(), gets null, and #activateTx(null) dereferences it. #advanceTxId/rejoin() are both plain synchronous functions, so when that crash happens during rejoin() or isolateForWrite()'s own catch-up call, it propagates synchronously into jUnlock/jLock's try/catch and surfaces as disk I/O error.

A quieter variant of the same gap produces database disk image is malformed instead of a throw: at exactly one generation behind, the +1 check can match a real file by coincidence — the wrong one relative to what the transaction actually names — and #skipTx never verifies the adopted file against tx.waSalt1. It silently continues with #activeHandle pointing at one file and #activeOffset describing a position in a different one. The next real page read pulls real, checksum-valid bytes from the wrong file at the wrong offset, and SQLite's own page-structure check reports corruption.

The fix

Three changes in src/examples/WriteAhead.js, all interdependent:

1. #skipTx adopts by verified salt match, not by generation hop. A new #adoptFileForSalt1(targetSalt1) checks both physical WAL files' real on-disk headers for the one that actually holds the target salt, instead of assuming a single hop forward. There are only ever two physical files, so if the transaction is still recoverable from disk at all, one of them names it exactly — this is what closes the malformed case, since it never adopts on a coincidental match anymore, only a confirmed one.
2. The pending-map delete moves to after #skipTx succeeds. If it still throws (neither file matches — genuinely unrecoverable from disk), the id stays queued instead of being lost forever, so a retry can make progress instead of repeating the identical failure at that #txId indefinitely.
3. #advanceTxId never calls #activateTx(null). If #readTx() finds nothing at the current position, it stops advancing for that call instead of crashing; the pending entries stay queued for the next broadcast or the backstop's readToCurrent pass.

Reproduction and verification

repro-345/ has a harness that reproduces all three symptoms deterministically — no real multi-tab reload race, no timing luck. It engineers the exact internal precondition each one needs and delivers it through the real, unmodified #handleMessage path via a genuine BroadcastChannel message (same shape a real peer's broadcast takes; nothing forged beyond ordinary public fields, no SDK internals called directly).

Results from this session:

Scenario	Result
invalid WAL file	5/5 runs
disk I/O error	2/2 runs
database disk image is malformed	3/3 runs
Fix, real broadcasts only (no synthetic data)	sawThrow=false sawUncaught=null readError=null writerRows=500 victimSees=500

repro-345/vendor/ is the unpatched code plus a handful of test-only fault-injection hooks (not part of the fix) that make the reproduction deterministic; repro-345/vendor-fixed/ is the same with this PR's fix applied. repro-345/README.md has the full writeup and exact steps to run it (python3 -m http.server + open the HTML pages in a Chromium browser).

---

@simolus3's reproduction repo and root-cause writeup on the issue is what let us pin down the exact mechanism — this PR follows directly from that.