Opening a read-only database makes it writable

[kevintseng]

What happens

If the database file is read-only (for example chmod 444 on a snapshot), the first memesh process that opens it changes its mode to 600. That process still cannot write (SQLite had already opened it read-only), but every later hook, CLI or MCP process opens it normally and writes into it.

Steps

1. chmod 444 ~/.memesh/knowledge-graph.db (on a copy).
2. Run any memesh command. The file mode is now 600.
3. Run memesh remember "x". The write succeeds.

Expected

memesh never loosens the permissions of a file the user protected; it only tightens permissions that are more open than 600.

[kevintseng]

Validated after PR #547 merged as 37fbb68 (tree 57ef95efedaa633058409f88ed18ba11ff7060a0).

Independent process replay on an immutable archive in an isolated HOME: 65 checks passed, exit 0. A 0444 database remains non-writable after reads; attempted writes exit 1 with database hash and rows unchanged. Partial sidecar permission changes are refused, full owner permission restoration permits writes, 0644 tightens to 0600, and a read-only directory is refused without creating files. Owned temporary processes and files were cleaned.

Same replay on first parent 9d4e5bb: exit 1, 35 failed checks, including 0444 becoming 0600 and writes incorrectly succeeding.

Main CI: https://github.com/PCIRCLE-AI/memesh/actions/runs/36840697450 — all 10 jobs successful, including Windows Node 22/24. CodeQL: https://github.com/PCIRCLE-AI/memesh/actions/runs/36840697393 — successful.

Limitations: Unix permission behavior was exercised on macOS; Windows CI does not establish Unix mode semantics. Real privileged root and read-only mounts/NFS were not exercised. Other non-database chmod sites remain outside this issue. This closes the reproduced database-permission defect, not overall release acceptance.