Explore OPFS write-ahead VFS mode

[marcus-pousette]

Summary

• Add experimental storage.writeMode: 'opfs-write-ahead' for wa-sqlite OPFSWriteAheadVFS.
• Add lifecycle coverage for reopening and for two dedicated-worker clients sharing one OPFS file.
• Add benchmark coverage for default OPFS, SharedWorker OPFS, single-owner WAL, write-ahead OPFS, and memory.

Why

This tests a possible Chrome/OPFS path where multiple clients can open the same local SQLite file directly.

The practical fallback is SharedWorker single-owner OPFS: one worker owns SQLite/OPFS, and tabs connect to it. That avoids duplicate local copies and keeps multi-tab support, but adds a message hop through the SharedWorker.

approach	shared OPFS file	runtime shape	concern
SharedWorker OPFS	yes	one DB owner, many tabs	SharedWorker message hop
OPFSWriteAheadVFS	yes	multiple DB owners	experimental Chromium-only path
separate stores	no	one DB per tab	redundant local data

Benchmark Scope

This is single-active-tab throughput. It measures how one tab performs while using a runtime that can still support additional tabs.

Local Benchmark

Chromium dev project on an M1 Pro:

workload	coop-sync ops/s	shared-worker ops/s	single-owner WAL ops/s	write-ahead ops/s	memory ops/s
insert-move-100	3,744	2,209	3,968	3,929	8,198
insert-move-1000	6,431	5,274	5,643	5,520	8,670
insert-chain-100	2,233	1,195	2,450	2,418	4,667
insert-chain-1000	720	687	700	706	730
replay-log-100	2,241	1,217	2,461	2,424	4,640
replay-log-1000	719	690	706	706	731