[codex] Add SQLite wasm OPFS backend package

[mandel59]

Summary

• Add @mandel59/mojidata-api-sqlite-wasm as an explicit browser SQLite wasm backend package.
• Implement a SQLite wasm OO1 SqlExecutor adapter, mojidata UDF registration, OPFS SAH pool install/import/manifest helpers, and a browser worker entrypoint.
• Extend the shared worker init protocol with optional SQLite wasm OPFS configuration and document the new package/release bootstrap path.

Validation

• corepack yarn workspace @mandel59/mojidata-api-sqlite-wasm test
• corepack yarn install --immutable
• corepack yarn workspace @mandel59/mojidata-api-sqlite-wasm npm publish -n --access public
• TypeScript compile for packages/mojidata-api-runtime

Related: #23

[mandel59]

レビューしました。mojidata-web-app 側からの利用可否としては、現状でも lower-level API を使って custom worker を書けば実装は始められます。ただし、package の browser-worker をそのまま使うには以下の修正が必要だと思います。

1. createSqliteWasmDbFromOpfsSAHPool() が両DBを eager import している

packages/mojidata-api-sqlite-wasm/lib/sqlite-wasm-runtime.ts:62 で mojidata と idsfind の両方に対して ensureOpfsSAHPoolDatabase() を先に実行しています。

web-appでは /mojidata/... は基本 moji.db だけ、/idsfind は基本 idsfind.db だけを使うため、初回 client-data load で両方の巨大DBをdownload/importするのは起動時間のregressionになりそうです。

ensureOpfsSAHPoolDatabase() は各 provider の中へ移して、実際にそのDBが初めて使われた時だけ materialize/open する形がよさそうです。

2. sqlite3.wasm のlocationをアプリ側から制御できない

packages/mojidata-api-sqlite-wasm/lib/opfs-sahpool.ts:71 の getSqliteWasm() が sqlite3InitModule() を引数なしで呼んでいます。

READMEではこのpackageは sqlite3.wasm をcopy/serveしない方針になっていますが、このままだと @sqlite.org/sqlite-wasm 側の new URL("sqlite3.wasm", import.meta.url) / bundler挙動に依存します。Next/OpenNext/Cloudflare と versioned SPA asset の構成では、web-app側から wasm URL か bytes を渡せる必要があります。

例えば getSqliteWasm(options) または worker init の sqliteWasm.wasmUrl / sqliteWasm.locateFile / sqliteWasm.wasmBinary 相当があると、web-app側で既存の asset配信・Cache Storage 経路に載せられます。

3. OPFS DB open後に PRAGMA temp_store=memory を設定したい

packages/mojidata-api-sqlite-wasm/lib/sqlite-wasm-runtime.ts:17 付近でDBをopenして executor化していますが、opfs-sahpool の capacity は temp/journal file にも影響されます。mojidata queryは CTE / INTERSECT / sort を使うので、初期実装では open後に PRAGMA temp_store=memory を設定して pool slot 消費を抑えたほうが安全そうです。

まとめると、PRの方向性とpackage境界は良いです。SqlExecutor backendとして分離されているので、web-app側実装は可能です。ただし browser-worker をそのまま採用するには、少なくとも eager import と wasm location 設定の2点は直したいです。