fix(storage): serialize concurrent first-open WAL initialization

[likun666661]

Summary

When two processes concurrently open the same not-yet-created SQLite runtime database, one or both openers can fail with:

Error: database is locked
    at configureSqliteRuntimeDatabase

The failure occurs at the setting form of:

PRAGMA journal_mode = WAL

PRAGMA busy_timeout = 5000 does not make this journal-mode transition reliably wait for the competing first opener.

Impact

A fresh workspace can fail startup when two Maka processes initialize the runtime store at the same time. Established WAL databases are not affected by this specific path.

This is not introduced by #1521. The PR improves the existing behavior but does not eliminate the first-open race, so this issue should not block that PR.

Reproduction

1. Choose a database path that does not exist.
2. Start two child processes behind a barrier.
3. Release both processes simultaneously.
4. In each process, call createSqliteRuntimeStore(dbPath) and close the store.

Repeated local results on Node 22.19.0/macOS:

• Current main 466f238b: 30/30 rounds had at least one failed opener; 58/60 openers failed.
• PR feat(runtime): establish Phase 3A recovery persistence authority #1521 head 1402c6b6: 18/30 rounds had one failed opener; 18/60 openers failed.

The PR-head stack points to configureSqliteRuntimeDatabase at db.exec('PRAGMA journal_mode = WAL').

Expected behavior

Both processes should open and close the newly initialized runtime database successfully without corruption or a startup error.

Suggested direction

• Serialize first-time journal-mode initialization, or add a bounded retry for SQLITE_BUSY / database is locked around the WAL mode transition.
• Preserve the optimized read-only path for already established WAL databases.
• Add a multi-process test where the database path does not exist before the barrier is released.
• Run the test repeatedly to make the timing-sensitive failure observable.

Related: #1521