fix(mcp): mark query tools as read-only - #502

Summary

This PR proposes advertising ChatLab's MCP query tools as read-only to clients, while making the underlying database access migration-free, transactionally consistent, and more narrowly scoped.

• Register the query tools with readOnlyHint: true, destructiveHint: false, and openWorldHint: false.
• Use MCP-specific, uncached native SQLite read-only connections inside short BEGIN read transactions. Read-only MCP requests cannot run migrations, modify logical chat records, or repair the compatibility marker. Existing CLI/Desktop writable and legacy read-analysis paths remain separate.
• Require supported current Schema (v10) for MCP queries: reject outdated v0–v9 sessions with explicit upgrade guidance; reject future and malformed schema versions; enforce the data-directory compatibility marker.
• Restrict MCP session IDs to real ChatLab database files in the configured session directory, rejecting traversal, unsafe paths, symlinks, and non-ChatLab databases.
• Reject dangerous user-supplied SQL before SQLite prepare (and before opening the database); allow SELECT/WITH queries while retaining SQLite's native read-only statement check.
• Close all per-request connections, including per-session enumeration, tool errors, and Resource failures. No full database/WAL copying or external temporary chat-data snapshots.

Maintainer decision requested: WAL/SHM versus readOnlyHint

There is an important, openly documented interpretation question. SQLite's native readonly: true connections do not intentionally modify logical chat content, Schema, or compatibility metadata, but ordinary WAL-mode reads can create or update -wal/-shm auxiliary coordination files. Consequently, they do not guarantee zero filesystem changes, and reads may fail on strictly read-only directories that require sidecar creation.

The readOnlyHint: true annotation here is proposed to preserve the original user-facing client read-only/approval behavior under a logical-data read-only interpretation. The MCP annotation's broader "does not modify its environment" wording may warrant the stricter interpretation instead. We request the upstream maintainer's decision on whether to keep this hint or adjust it and the PR's scope; the hint is not a security boundary.

A previous attempt to avoid all source-directory sidecar changes by copying the entire DB/WAL on every request was removed after independent architectural review: it had unacceptable resource/privacy costs and could read uncommitted rollback-journal pages. Native SQLite transactions give the consistent committed snapshot we need; this revision intentionally does not restore the full-copy workaround.

Verification

• 111/111 targeted tests pass (MCP Tools/Resources, actual client annotations and SQL pre-open checks, path and symlink boundaries, real v4 legacy migrations, Schema v0–v11 and malformed values, compatibility markers, CLI analyzeAutoImport regression, live WAL snapshots, rollback spill, and connection closure).
• pnpm --filter chatlab-mcp build, ESLint, Prettier, and git diff --check: pass.
• The existing workspace-wide type-check:node is still not clean (55 diagnostics, primarily unrelated CLI dependencies/typings in the sandbox); there are no diagnostics in the revised/new file paths.
• Fresh GitHub CI and actual Windows/macOS filesystem behavior not yet verified.

Scope: MCP querying is logically non-writing but is not promised to be zero-filesystem-side-effect. Historical databases must be explicitly upgraded by a writable ChatLab runtime before MCP can query them.