fix(mcp): Bound cancellable project scans

[reneleonhardt]

What does this PR do?

Propagates request cancellation through scanner, Git, handoff, and MCP traversals, and bounds project and manifest discovery.

Type of change

• Bug fix
• New feature
• New language support
• Documentation
• Other (describe below)

Checklist

• I've tested this locally with go build && ./codemap .
• I've read CONTRIBUTING.md (for new language support)
• I've updated documentation if needed

Additional notes

Legacy non-cancellation scan failures remain best-effort.

Co-Authored-By: GPT-5.6 Sol codex@openai.com

[JordanCoin]

Reviewed — this is strong. Threading cancellation so a client-aborted MCP call actually kills the sg/git subprocesses is a real gap, cmd.WaitDelay is the right call, and traversalRoot incidentally fixes the relative-vs-abs inconsistency where handlers passed input.Path to some scanners and absRoot to others.

Two notes:

1. This collides semantically with #97, not just textually. Both rewrite ScanForDepsWithFilters and the same error block in ScanDirectory — #93 keeps graceful degradation (return nil, nil on timeout) while #97 turns those exact lines into hard errors. Whichever lands second has to reconcile the intent, not just the text. Landing #93 first and rebasing #97 on top seems cleanest, since fail-closed can then be expressed inside the Context variants.

2. The XxxContext twins are back-compat we don't need. module codemap has no external importers, so ScanFiles/ScanForDeps/ScanConfiguredFiles/GitDiffInfo/AnalyzeImpact/ReadExternalDeps could each just take a ctx instead of gaining a sibling. As-is we're accumulating axes: with #97 also adding an Outcome variant, ScanForDeps ends up as WithFilters × Context × Outcome. A single ScanForDeps(ctx, root, filters) (ScanOutcome, error) collapses all three — worth doing while there are only two callers' worth of churn.

No objection to the substance; both are shape questions.