fix: don't leak a user-provided fs into the inner initdb instance

[AntonOfTheWoods]

Creating a fresh database boots a second, inner PGlite instance to run initdb, built from a shallow copy of the caller's options with dataDir, extensions, and loadDataDir cleared — but not fs. A user-provided filesystem instance therefore had its init() called a second time by the inner instance, colliding with resources the outer instance already holds. For OPFS-based VFSs (whose sync access handles are exclusive per file) this makes any fresh PGlite.create({ fs }) fail with NoModificationAllowedError; the dataDir-scheme paths never hit it because the inner instance falls through to a scratch memoryfs.

Clear fs alongside the other per-store options so the inner initdb instance always runs on its own scratch filesystem.

[AntonOfTheWoods]

CI note on the two red runs, for whoever reviews:

• Run 1 failed in the pg_textsearch WASM build — make[1]: *** [src/memtable/cache.o] Error 120 with no compiler diagnostic anywhere in the log (parallel emcc build dying, not a source error).
• Run 2 (after a content-identical retrigger) got past the WASM build and failed only in the Linux-WebKit web targets with RuntimeError: Out of bounds memory access in the WASM table dispatch — a different WebKit file per retry attempt (webkit-idb 8/8, webkit-memory 4/4) while every Chromium and Firefox target passed ("1 failed | 8 passed (9)" on each attempt).

Neither failure intersects this diff: it's TypeScript-only (pglite.ts + a test + a changeset), and the failing web targets boot via memory:///idb:// dataDir strings, so the changed options.fs path is never exercised there — for them the added pgInitDbOpts.fs = undefined assigns undefined over undefined. I've retriggered a third run; flagging the pattern here in case these are known runner flakes on your side.