fix(wa-sqlite): allow long OPFS database paths

[marcus-pousette]

What

Allow valid OPFS database paths longer than wa-sqlite's 64-byte VFS default.

TreeCRDT now advertises a 512-byte pathname capacity before registering either OPFS VFS:

• CoopSync in dedicated workers.
• AnyContext in direct/main-thread mode.

Why

SQLite appends sidecar names such as -journal and -wal after checking the VFS pathname capacity. A 58-byte database path therefore becomes a 66-byte journal path and fails with the generic SQLITE_CANTOPEN / sqlite3_open_v2 error when the VFS reports 64 bytes.

This was reproduced exactly in Chromium:

• 54-byte database path, 62 with -journal: opens.
• 58-byte database path, 66 with -journal: fails with the old limit.
• The same 58-byte path opens when the VFS advertises 512 bytes.

The failure looked like an OPFS drop/reopen race in #164 only because its normal-priority filename was four characters shorter than its background-priority filename.

Scope / fast paths

• 3 files, +20/-3.
• One VFS wrapper change; no vendored/generated files.
• No database format, journal mode, locking, worker lifecycle, or sync behavior changes.
• Runtime and storage fast paths are unchanged; this only enlarges SQLite's pathname buffer.
• Independent of fix(wa-sqlite): recover cleanly from OPFS initialization failure #208, fix(wa-sqlite): terminate shared clients on database drop #209, and the scheduler stack.

Regression coverage

The existing browser lifecycle matrix now deliberately uses a database path whose -journal form exceeds 64 bytes. It covers both direct/AnyContext and dedicated-worker/CoopSync clients, explicit close and reload teardown, persistence, and drop cleanup.

Verification

• wa-sqlite TypeScript build passes.
• Prettier and git diff --check pass.
• Playwright covers all four long-path lifecycle scenarios.
• Full GitHub build, browser, native-node, playground, and Postgres CI is green.