fix(graph): read impact's knowledge links from the committed scaffold (#224)

[theyashasvipandey]

Closes #224.

Problem

mex impact read knowledge links only from the _mex_grounded_source cache in .mex/graph.db. Only setup, mex sync and mex graph ground fill that cache; mex graph, rebuild and refresh never do. So a fresh clone plus a build returned no knowledge links, and a checkout whose Markdown had moved on kept returning links the scaffold had dropped.

Change

• impact now reads grounds_to from the committed scaffold at query time, through extractGroundings(), so root, mex: and mixed shapes (Root-level grounds_to is invisible to check and wiki for-code in files that also have a mex: map #226) all count.
• Files are found and read with the Wiki index's own contained, bounded walk and reader (discoverMarkdownFiles, readContainedSource, WIKI_CORPUS_LIMITS), honouring wiki.exclude. impact therefore sees the same files as wiki for-code.
• A grounding recorded under a renamed node's old id still attaches to the current node through node_aliases.
• Existing behaviour is kept: the drifted-file exclusion, the { type: "grounding", node, file } record shape, and the admission order from impact drops grounding records first when it runs out of budget #225.
• Nothing is dropped silently. A new grounding-omitted record covers three cases:
  • scaffold-unreadable: lists files that couldn't be read within bounds (capped at 20).
  • scaffold-limit: a scaffold-wide limit stopped the walk.
  • scaffold-changed: the scaffold changed during the call (checked by file identity before output), so every grounding record is withheld.
• _mex_grounded_source stays in place for check's baselines.

Reproduction: mex repo, committed 975f152, graph-only build

Surface	main	this PR
impact, default budget	0/12	11/12
impact --max-output-tokens 20000	0/12	11/12
wiki for-code	12/12	12/12

The twelfth grounding (rebuildGraph in patterns/safe-graph-snapshot-evolution.md) names a node id that no longer exists and has no alias. mex check reports it as GROUNDING_AMBIGUOUS / GROUNDING_GONE, so it needs a scaffold fix. for-code only returns it because the dead id is passed in directly.

Latency: about +0.65 s per impact call on this repo (7.2 s → 7.9 s, median of 9). About 350 ms is loading the YAML/Markdown parser that extractGroundings() needs, and about 250 ms is the contained reads. Only each file's frontmatter block is parsed; this gave identical results to a full parse on all 145 files across five real scaffolds.

Behaviour changes to review

• Anchor-only links are no longer returned. A link that exists only as an inline mex:// anchor is dropped, because the cache held anchors too. The 4 Hono rows the issue called stale are anchors like this. The Wiki doesn't index anchors as groundings, so including them would break the match with for-code. mex check still verifies anchors.

• Two remaining differences from for-code, both in how the Wiki indexes files:

  • A pre-wiki file with only a root grounds_to has no Wiki entity, so impact returns it and for-code does not.
  • Groundings inside <!-- mex:entity --> blocks are read by for-code only.

  Both are documented in src/committed-groundings.ts.

Tests

• New: test/graph-impact-committed-groundings.test.ts, 7 tests, each failing against main's source and passing here:
  • fresh clone with an empty cache
  • stale cache row
  • renamed-node alias
  • root, mex: and mixed shapes
  • file over the size limit
  • scaffold changed during the call
  • same files as wiki for-code
• Updated: impact unit tests in test/graph-cli-agent.test.ts now declare their groundings in real scaffold files instead of a fake cache row.
• Scoped run: 154 pass, 2 fail. The two failures are in test/graph-cli-freshness.test.ts and fail identically on main (known local Windows baseline).
• The full suite has not run yet (the local run was stopped because the machine ran low on memory). CI will cover it.