fix(mcp): preserve exact-path coverage when ignored records truncate

[SunneeYang]

What does this PR do?

Fix exact-path coverage checks when the ignored-file catalog is truncated.

A repository with more than 2,000 ignored files records recording_status: "truncated". The previous logic treated that global catalog state as proof that every coverage query was unavailable, even when an exact source path had a current hash record and freshness: "metadata_match".

This change allows an exact path to return no_recorded_issue only when:

• the generation matches
• the coverage lookup succeeds
• hash records are complete
• file metadata matches

Explicit partial, excluded, and skipped records still take precedence. Scope queries and stale, missing, or failed lookups remain conservative and return coverage_unavailable.

Fixes #1613

Validation

• Focused MCP tests: 180 passed, 2 skipped
• Added regression coverage for a truncated ignored catalog with an exact fresh path
• Full suite: 6786 passed, 2 failed, 4 skipped; remaining failures are environment-related (Hermes cleanup and an active CBM session preventing lifecycle teardown)
• CI-equivalent lint passed locally with LLVM 20.1.8 and cppcheck 2.21.0: scripts/lint.sh --ci CLANG_FORMAT=/opt/homebrew/opt/llvm@20/bin/clang-format

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[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.