data: opencode.db is created world-readable (0644), bypassing service API auth for local users #50673

Summary

~/.local/share/opencode/opencode.db is created mode 0644 (world-readable)
under a 0755 directory on a default umask 0022 system, while the background
service API correctly requires authentication (401). Any local user or process
can read session/message/credential data directly from the SQLite file,
bypassing service authentication entirely.

Environment

• opencode version: 2.0.14
• OS: Linux 6.18.33.2-microsoft-standard-WSL2 (applies to any Unix host with umask 0022)
• Terminal: TERM=xterm-256color
• Shell: /bin/bash
• Install/channel: latest
• Active plugins: none found in config

Reproduction

1. Run opencode so the background service creates the database.
2. Inspect permissions:

   $ umask
   0022
   $ ls -ld ~/.local/share/opencode
   drwxr-xr-x 6 <user> <user> 4096 ... ~/.local/share/opencode
   $ ls -l ~/.local/share/opencode/opencode.db
   -rw-r--r-- 1 <user> <user> 15310848 ... opencode.db
   

3. As any other local user (no service password needed), open it read-only:

   sqlite3 'file:~/.local/share/opencode/opencode.db?mode=ro' '.tables'
   

   (sqlite3 CLI Unavailable in my env — not installed; used Python's sqlite3
   module with a mode=ro URI, no sudo, no service credentials.)
4. Tables include: message, part, session, session_v2,
   session_message, session_inbox, session_share, credential, ...

Expected Behavior

The database (and any credential storage) should be created 0600, consistent
with ~/.local/state/opencode/service.json and
~/.config/opencode/service.json, which are correctly created 0600. Service
auth should not be the only barrier protecting session content.

Actual Behavior

The db file is 0644 and its parent directory 0755, so any local account can
read it with a plain file read — no 401, no password. Table structure confirms
message/session/credential-class content. (I did not dump row contents; the
finding is permission-level.)

Additional Context

• Registration/password files verified 0600 — good; the db was likely just
  missed because SQLite creates files with the process umask.
• OPENCODE_DB can relocate the database; the same restrictive default should
  apply there.
• Likely fix: chmod 0600 after create (and tighten on startup for existing
  files), or set a restrictive umask around db creation.
• Frequency: consistent — it follows from umask 0022, the default on most
  distros.