fix(wiki): give the Wiki CLI the code graph, and fix the drift verdicts it exposed (#232)

[theyashasvipandey]

What

The Wiki commands that resolve groundings now use the code graph. Before this, they ran without one, even in a checkout with a fresh graph.db:

• wiki validate always reported codeGraphAvailable: false.
• wiki rebuild-index stored NULL health for every entity, so --health changed matched nothing.
• wiki migrate never backfilled bodyHash.
• wiki apply could not ground.

validate, rebuild-index, migrate, apply and regenerate-views now reach the graph the way the Project Hub does: through the repository graph port, with one revocable snapshot per command. The snapshot is proved fresh again before anything derived from it is reported.

• Rebuild: rebuild-index uses the port's two-phase publication, so it never stores health from a graph that changed while it was being built.
• Unusable graph: if the graph is stale, incompatible, corrupt or changes during the pass, it isn't used. The command does its work without it and adds the info notice CODE_GRAPH_UNAVAILABLE, which says why and names mex graph.
• No graph: a checkout without a graph stays quiet, as before.
• No bridge: a caller that supplies no bridge is never reported as a checkout without a graph.

Once the graph was wired in, four faults it had been hiding surfaced. Each has its own commit:

1. Index writes ignored the graph (5435b8a). wikiRebuildIndex dropped the graph it was given, and the post-write refreshes of apply, migrate and regenerate-views had no resolver. One resolver now goes through rebuild, refresh and every post-write refresh.
2. Migration backfill would have erased drift (dcecd99). It wrote the current body hash for any legacy grounding whose node resolved, which permanently hides any drift since grounding. It now uses the same evidence order as capture's legacy backfill:
   • the baseline mex ground cached, when its fingerprint is the committed one;
   • otherwise the current body, but only for the declared node whose fingerprint still matches;
   • otherwise nothing.
3. Re-minted ids read as changed (33abbbe). A grounding reached through a compatibility alias (TypeScript node ids change with the checkout directory: groundings and mex:// anchors don't survive a clone to another path #240), or rebound by reconciliation, was judged by fingerprint, and the re-mint renumbers neighbour ids. A body byte-identical to the committed hash now resolves fresh. A body that differs is still judged by structure, so a rename stays fresh.
4. Neighbour changes read as code changes (4802782). A grounding with no bodyHash was compared on the whole fingerprint, neighbour ids included. Those change when a caller elsewhere is added or ids are re-minted. The change verdict now compares only the MinHash sketch and token count, via the new sameFingerprintCode. Identity checks keep the full fingerprint.

Why

Closes #232.

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• CI/Tooling

How to test

1. In a checkout with a fresh graph, run mex graph, then mex wiki validate --json. Expect codeGraphAvailable: true, groundingsUnverified: false, and GROUNDING_STALE for any drifted grounding.
2. Run mex wiki rebuild-index and then mex wiki list --health changed. The drifted entities are listed.
3. Edit a grounded function's body without rerunning mex graph, then run mex wiki validate. Expect CODE_GRAPH_UNAVAILABLE ("out of date with the source") and no verdicts.
4. Run mex graph, then mex wiki validate again. The edited grounding reports GROUNDING_STALE, and mex check reports GROUNDING_DRIFT for the same node.

Measured on two populated scaffolds:

• Hono. Validate and the index went from resolving nothing to the same verdicts as mex check: 7 groundings fresh. After editing #dispatch, both groundings on it were flagged by validate, the index and check. Before fix 3, 2 entities there read changed with byte-identical bodies.
• A second scaffold built before TypeScript node ids change with the checkout directory: groundings and mex:// anchors don't survive a clone to another path #240. Before fix 4, 3 entities read changed with identical MinHash (64/64) and token counts. Now all 8 groundings are fresh, matching mex check.
• Migrate with a fresh graph. It applies, and its post-write refresh records health.

New tests:

• src/wiki/service/__tests__/grounding-health.test.ts: rebuild, prepared rebuild (commit and discard), and refresh health.
• src/wiki/cli/__tests__/grounding.test.ts: fresh, stale, missing and moving graphs for validate and rebuild-index; a write is never run twice; a read is re-run without the graph; unexpected bridge errors are rethrown.
• src/wiki/migration/__tests__/grounding.test.ts: historical-baseline backfill, and no backfill without evidence.
• src/wiki/grounding/__tests__/resolve.test.ts: alias with an identical body, and a neighbour-only fingerprint change.
• src/graph/__tests__/fingerprint-encoding.test.ts: sameFingerprintCode.
• diagnostic-coverage.test.ts: emits CODE_GRAPH_UNAVAILABLE.

Checklist

• Tests pass (npm test), apart from failures that also occur on stock main on this Windows machine. Full suite: 4,345 passed, 31 failed.
  • Re-run on stock main d0d402b, same results:
    • wiki-sweep.test.ts (script import);
    • graph status, freshness and integration atomic-replace tests;
    • cli-agent.test.ts (EPERM).
  • Known baseline:
    • the 3–5 load-dependent migrate.test.ts 30 s timeouts;
    • concurrency.test.ts "answers reads correctly while a refresh is in flight".
  • Not re-run on main: the remaining failures are in Team, setup and release-benchmark, which this PR doesn't touch.
• No breaking changes (or documented below)
• Tested locally with a real project

Compatibility. CODE_GRAPH_UNAVAILABLE is a new Wiki diagnostic code, at info severity. wiki validate can now report GROUNDING_STALE, GROUNDING_MISSING and GROUNDING_UNRESOLVED on scaffolds where it reported none. All are warnings, so its exit status is unchanged. Index and graph schemas are unchanged. Run mex wiki rebuild-index once to record health in an existing index.

Not in this PR. wiki build/prepare/propose (synthesis) still open graph.db directly, without the freshness proof. This is recorded in the scaffold ROUTER.

Code-graph changes

• This PR targets main
• A linked issue agrees on the bounded extractor/resolver scope
• The change follows the frozen LanguageExtractor or FrameworkResolver interface
• A focused fixture and assertions for the expected node/edge shape are included
• Any new grammar WASM, extension mapping, extractor, or resolver is registered
• No graph identity, reconciliation, schema, or drift-semantics changes are included, or a core / discuss-first issue is linked above

No extractor, resolver, identity, reconciliation or schema change. The only graph-side addition is the read-only helper sameFingerprintCode in src/graph/fingerprint.ts. The drift-semantics changes are on the Wiki side (fixes 3 and 4), and each makes the Wiki agree with mex check where the two disagreed. They are linked to #232 here rather than to a separate discuss-first issue.