The CLI migrates the project schema behind the server's back

[EdmondDantes]

Defect

Every CLI command opens the project's SQLite read-write and runs the schema migration on it, including commands that only read — and including while the server is running against the same file.

resolve() goes through ProjectStore::discover() (Cli/WorkflowMode.php:493) to openHandle() (ProjectStore.php:829-832), which is open() plus ensureSchema(); ensureSchema() issues CREATE TABLE IF NOT EXISTS and addMissingColumns() runs ALTER TABLE (ProjectStore.php:884, 909-913). So a plain claw log can migrate the database the server is writing to. The comment at Cli/WorkflowMode.php:179-180 calls the handle read-only; at the storage layer it is not.

This is the loose end of the thin-client work (#91–#96): the run moved to the server, the schema authority did not.

Why it matters now

With the server about to run several workers, "who may migrate the schema" stops being a formality — a migration racing a live writer is the one failure that costs data rather than a request.

Sketch

• A read-only open that does not migrate, used by every CLI path that only reads.
• The schema stays the server's, or is claimed once by whoever creates the project.

Acceptance

• claw log against a database missing a column fails with a clear message instead of silently altering the table.