fix: CLI read-only commands grab a write-capable connection, colliding with a live watcher

[pradeepmouli]

Addresses the specific symptom named in #46: infigraph query / get_file_deps (and 15 other CLI commands) failing with "graph is locked by another infigraph process" while a watcher is running.

Root cause

Not the deeper concurrent read/write question #46 raises (tracked separately upstream at LadybugDB/ladybug#766, found while investigating this) -- it's much simpler: 17 CLI commands whose MCP tool counterpart already correctly opens read-only (open_prism_read_only/init_read_only()) instead opened write-capable (prism.init()). That's an ordinary write-vs-write conflict Kuzu correctly and permanently rejects -- caused entirely by these commands unnecessarily requesting write access for what is, in every case here, a pure read.

Fix

Converted (CLI command -> underlying connection mode, mirroring the already-correct MCP tool):
query, symbols, stats, snippet, routes, find-refs, api-surface, file-deps, type-hierarchy, test-coverage, complexity, skeleton, files, test-context, sequence, review, search

query's cypher is arbitrary user input, but rather than inspect it for write statements, this mirrors query_graph's existing MCP behavior exactly: open read-only and let the backend reject write statements with its own clear error ("Cannot execute write operations in a read-only database").

memory-context needed no change -- it already delegates directly to tool_memory_context, which was already read-only.

The remaining 36 write-capable CLI call sites are unchanged: either genuinely write-oriented (index, group build/index, delete, ingest), or their MCP counterpart is also write-capable (the whole analysis/ module -- dead-code, callers, callees, impact, taint, security, clones, etc. -- none of which use open_prism_read_only on the MCP side either), so those aren't CLI/MCP mismatches and are out of scope here.

Verification

• Started a real infigraph watch, confirmed via watch-status it was alive both before and after, and ran infigraph query against it mid-session -- succeeds cleanly now, where it previously failed with "graph is locked by another infigraph process".
• cargo test -p infigraph-cli (69 unit tests + cli_parity integration tests): all pass.
• cargo fmt -- --check / cargo clippy --all-targets -- -D warnings: clean.

Relation to #43

Independent of #43 (and the reason this is a separate PR, not bundled with it) -- #43 addresses the deeper "watcher holds one connection open for its whole session" design tradeoff, which per the discussion on #46 needs a combined solution with #46 before merging. This PR fixes a much narrower, unrelated bug: commands that never needed write access in the first place. It can land independently of how #43/#46 get resolved.

Follow-up

This class of bug (structurally identical connection-opening logic duplicated between infigraph-cli and infigraph-mcp, free to drift out of sync) is now filed as supporting evidence on #24 (deduplicate CLI and MCP tool implementations).