fix(mcp): skip direct store open for invalid project names

[dergachoff]

Problem

A query with an invalid project name (bad name, #upstream) makes the server write a .corrupt.<hex> file into the process's cwd — for the daemon, whatever repo it was started in. One 4096-byte file per query, invisible to the caller, who just gets "project not found". Fixes #1425.

Root cause

project_db_path() returns "" on validation failure. resolve_store_internal() passed it to cbm_store_open_path_query(""), which SQLite opens as an anonymous temporary database. The temp db fails the integrity check (no projects table), so the recovery path "quarantined" it: "%s.corrupt.%016llx" of an empty prefix is a relative path, created in cwd.

Fix

• resolve_store_internal(): skip the direct open when the path is empty, fall through to the query_graph / search_graph return "project not found" inconsistently; DBs valid on disk but CLI looks up wrong inode #704 internal-name fallback scan. A typo still returns not-found; a legacy db with an invalid internal name can still resolve.
• quarantine_corrupt_store(): refuse an empty path (defense in depth; unreachable via the resolver now).

No behavior change for valid names: validation passing always yields a non-empty cache_dir/<project>.db path.

Validation

• New test tool_query_invalid_project_name_no_corrupt_litter: query with project:"bad name" from a scratch cwd asserts the not-found reply, zero recovery-lease acquisitions, and zero .corrupt entries in cwd and cache dir.
• Red without either guard (log shows the reported path= signature); green with both. mcp + mcp_mutation_guard: 214 passed, 2 skipped.
• Live-reproduced the litter on 0.9.1-rc.1 before the fix (details in Invalid project name resolves to empty db path — daemon litters .corrupt.<hex> files into its cwd #1425).

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[dergachoff]

Duplicate of #1437 (same guards, same test) — closing in favor of the maintainer's version. Happy to port anything if it turns out mine covered a case yours doesn't.