fix(mcp): flag source drift in get_code_snippet and search_code (#1750)

[umi008]

What does this PR do?

get_code_snippet and search_code sliced the live file on disk using line coordinates recorded at index time. After the file was edited without re-indexing those ranges are stale, and the tools returned shifted source text — a grep hit misattributed to an adjacent function, or a snippet of the wrong symbol — presented as though it were current source.

Both tools now consult the same freshness oracle check_index_coverage already exposes. When the recorded metadata no longer matches the file on disk (metadata_changed/missing), they skip the stale live slice and report source_drift: true plus the freshness state instead. The healthy path (metadata_match) is byte-identical to before; re-indexing remains the remedy.

Tested with two reproduce-first regression tests: a snippet request and a full-mode search after a file is modified on disk (asserting source_drift and no stale text), plus the unchanged clean-metadata path.

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.

[DeusData]

Thank you for identifying a correctness problem that can make stale coordinates look authoritative, and for covering both snippet and search paths. I checked current main: get_code_snippet and search_code still consume stored start and end lines for live-file slices without first applying the existing freshness result. That grounds the source-drift failure described here.

There is one mechanical scope blocker before code review. This PR adds 196 lines across seven new openspec/ files, including project configuration, while current main has no openspec/ tree and CONTRIBUTING.md requires prior approval for project configuration. Please remove the entire openspec/ portion and keep the focused MCP change plus tests. I have labeled the underlying problem as a high-priority parsing and correctness bug. Splitting enables review but does not pre-decide the merge outcome. Thank you for the clear reproduction and fail-closed response shape.