[FEATURE]: Project-scoped stores — split the global session DB into a system DB + per-project DBs

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

I'd like to suggest splitting the single global session DB into a small system DB plus one DB per project — system DB for accounts/credentials/migrations plus a session catalog, per-project DBs for session/message/part/event and the rest. The goal: keep opencode fast under heavy parallel use across many projects over months. Full write-up with measurements: https://gist.github.com/aschokinatgmail/9859bf951129a1f64cf1cbd3f9ad300b

Why I'm asking. My daily driver (4-core/32GB laptop) ran opencode for 5 months with heavy multi-project use. The DB grew to 34 GB and the whole machine crawled: SELECT COUNT(*) FROM part took 26.7 s (0.02 s after cleanup), kernel sys-time ~41.5%, load average 25–62. Hand-pruning it to 2.1 GB dropped load to 1.8. I did that pruning manually with the sqlite3 CLI because nothing in opencode maintains storage today (#41175 shows other users doing the same by hand).

What's new here vs. the existing threads (#47223, #33356, #41175, #16101 — which I support; my numbers confirm the journal-growth diagnosis: 14.5 GB of 17 GB was the event journal): those fix growth within the one big DB. This is a different, complementary layer — scoping. Today one WAL means one global writer, so a heavy project blocks writes in every other project; one runaway project (one of mine held 52% of the DB) taxes everyone's latency; and a single file forces one retention policy on all projects. Splitting scopes each project's writes, blast radius, and retention to its own DB — and stays valuable even after the journal fixes land.

Suggested properties (details up to maintainers): stable project ID created once and stored in the project (not a path hash — survives renames/moves/worktrees); catalog as a derived, rebuildable cache; central data dir by default ($XDG_DATA_HOME/opencode/projects/<id>/). Migration should be lazy and opt-in — new sessions go to per-project DBs, the legacy global DB stays a read-only archive (my 34 GB VACUUM needed exclusive access for minutes — don't force that on first run).

Acceptance criteria, adoption path, and risks (concurrent-writer benchmarks for both SQLite drivers, fd limits for serve mode, cross-project parent_id sessions) are in the gist.

Related: #47223 #33356 #41175 #16101 #47022 #46833 #42748 #31526