feat(analysis): Add structured dependency contract

[reneleonhardt]

feat(analysis): Add structured dependency contract

What does this PR do?

Adds versioned, deterministic dependency JSON and MCP structured output for agentic coding in isolated worktrees and restricted sandboxes while preserving the existing text response. Coverage remains explicit, including known partial Rust analysis.

The contract lets CLI and MCP clients consume the same machine-readable dependency graph:

codemap --json --deps .

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

Also stabilizes the pre-existing Linux debounce test by making its write burst unambiguously shorter than the production debounce window.

Verification: go test ./analysis ./scanner ./mcp . -count=1; Linux Go 1.25 race suite.

Developed with carefully directed, manually reviewed AI assistance.

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

[JordanCoin]

Reviewed. Schema-versioning the deps output and sorting Files/Functions/Imports for deterministic JSON are both clear wins, and detecting Rust from the file inventory rather than only from analyses is the truthful fix — a project with Rust that ast-grep produced no matches for should still report partial coverage.

Three things:

1. analysis.Source duplicates what #97 adds to scanner. #97 introduces scanner.ScanSourceOutcome{Source,Status,Detail} plus ScanSourceStatus with the exact same six values as analysis.SourceStatus. Two packages, one vocabulary. Since this PR creates analysis explicitly as the shared contract, #97 should consume it — but that's only true if this lands first. Worth deciding the direction before either merges.

2. The inventory costs a second full filesystem walk. runDepsMode now calls ScanFiles in addition to ScanForDeps, and handleGetDependencies adds ScanConfiguredFiles — both purely to answer "does this project contain Rust". On a large repo that's a doubled walk on every --deps invocation for one coverage flag. Could the walk be shared with the one BuildFileGraph already does, or the check be narrowed to an early-exit scan that stops at the first .rs?

3. NewDepsProject(..., inventory ...[]FileInfo) uses variadic as an optional param. Only inventory[0] is ever read, so the signature promises something the body doesn't honor. A plain inventory []FileInfo parameter (nil when unavailable) says the same thing without the ambiguity.

Also: the Rust check is hardcoded into a generic constructor, so it'll need editing per language that gains partial coverage. Related to (1) — if the provenance vocabulary is shared, this could be data-driven instead.