[Feature]: let an MCP tool call name its own graph data directory

[felipecaldas]

Problem

One MCP server answering for several repositories cannot give each one its own graph data
directory.

Moving the database off the working tree is already supported, and I use it: the repos I work in
live on a Samba mount where SQLite access is unreliable, so every graph has to live under
~/.crg-graphs/<repo>/. Two mechanisms exist and both are process- or machine-wide:

Mechanism	Scope	Why it does not cover this
CRG_DATA_DIR	whole process, one path used verbatim	eight repos would share one directory
registry entry	one repo, durable	only a CLI run writes one; an MCP-only client cannot

So today the MCP server resolves the right directory only if someone has already run the CLI once
per repo to seed ~/.code-review-graph/registry.json. That works on a developer laptop. It does
not work for a client that speaks only MCP, or in an ephemeral or read-only environment with
nowhere durable to keep the registry.

The practical symptom is smaller than it sounds and I want to state it plainly rather than
oversell it: the tools are usable, they just cannot be told where to look. Resolution depends on
ambient global state the call cannot see or set.

Proposed solution

An optional data_dir on the graph-backed MCP tools, checked ahead of the registry and
CRG_DATA_DIR:

{ "repo_root": "/repos/api", "data_dir": "/var/graphs/api" }
{ "repo_root": "/repos/web", "data_dir": "/var/graphs/web" }

It would write no registry entry and affect only the call that passes it. Omitted, resolution stays
exactly as it is now, so nothing changes for existing clients.

Plus serve --data-dir as the default for calls that pass none, for the ordinary single-repository
server. Unlike build --data-dir, it would not write a registry entry.

This mirrors repo_root and _resolve_repo_root one for one, which is what makes it cheap to
review: the same precedence shape, an explicit argument beating a server flag beating the existing
fallback.

I have this working and will open a PR against main if you are open to the idea. It also covers a
small gap I found on the way: detect-changes is already in the CLI's _data_dir_cmds and already
resolves a read-only database path from args.data_dir, but its parser never defines --data-dir,
so that branch is currently unreachable.

Affected area

MCP tools / server

Alternatives considered

• CRG_DATA_DIR in the MCP server env. Correct for one repo per server, and what I would
  recommend to anyone in that situation. It is one path for the process, so it cannot express per
  repo directories.
• Seed the registry from the CLI once per repo. This is what I do today and it works. It makes
  a CLI run a prerequisite for correct MCP behaviour, and puts the answer in machine-global state
  rather than in the call.
• One MCP server per repository. Sidesteps it, at the cost of a server process per repo.
• A set_data_dir tool. Rejected: it is the same global mutable state, reachable from a tool
  call, which seems worse than an argument.

Additional context

This is a #155's follow-up, the --data-dir CLI work you merged in e46341b. This is the MCP half
of the same idea; I kept it local at the time and should have sent it then.

Unrelated, and I will file it separately if you would rather, but I hit it while running your suite:
test_explicit_repo_without_markers_errors_cleanly fails on a clean checkout for me. The upward
marker walk finds ~/.code-review-graph, code-review-graph's own registry directory, and treats it
as a project root, so any temp directory under $HOME resolves instead of erroring.