fix(grounding): commit the body hash to Markdown, and make the reads that use it agree

[Yashasvi2229]

What this fixes

The value that answers "has this grounded code changed?" was captured at
saveCurrentBaseline and written only into _mex_grounded_source inside
.mex/graph.db — a file that is gitignored, disposable by invariant, and whose
deletion the product recommends as a routine repair. So the drift baseline did
not survive mex graph rebuild and never reached a teammate who cloned. The
groundings still resolved, so nothing looked broken; they simply stopped being
able to detect a body change.

bodyHash is now committed to Markdown alongside node and fingerprint.

The field alone would have been inert. Two reads had to change with it, and
the second was found only by running against a real migrated scaffold:

1. The drift checker took the baseline exclusively from graph.db. After a
   rebuild that row is gone and the branch reported nothing at all — not a
   coarse verdict, nothing.
2. The same checker read frontmatter.grounds_to, the root key. A scaffold
   wiki migrate has adopted keeps the key under the mex map, so the loop ran
   zero times — as did the hasGroundings gate, which then never opened the
   grounding runtime. On the scaffold this was found on, mex check had never
   checked a single grounding, on any run, and reported clean.

Two diagnostics that named a cause nobody checked are also corrected.

Measured, on a real migrated scaffold

25 files, 27 entities, 16 groundings, graph.db fresh. Identical throwaway
copies, before and after:

	before	after
capture reports	16 captured, 0 skipped	16 captured, 0 skipped
groundings carrying a bodyHash	0	16
wiki validate warnings	16	0
delete graph.db, rebuild, edit a grounded body	0 GROUNDING_DRIFT	2 GROUNDING_DRIFT

Before this branch the capture printed "16 captured, 0 skipped" and wrote
nothing durable.

Backward compatibility

Optional and additive — a required field would turn every existing scaffold into
a parse error. A grounding with no bodyHash still parses, still validates,
still warns, and against a live index still detects drift from the graph.db
cache, which remains as a documented fallback and still carries the body text
drift review needs for a diff.

A hash that merely differs is never overwritten. That difference is the
drift; re-baselining it silently would erase the finding.

Tests

Five new cases in test/graph-grounding-body-hash.test.ts, each deleting
graph.db and rebuilding it — the thing that used to destroy the baseline.
Two fail on the pre-fix tree and three pass, verified by restoring the base
files and re-running; the three that pass are backward-compatibility pins and
are meant to be insensitive to the fix. Run five times, 5/5 green each time.

Known-red, and not from this branch

release-performance is failing on integration/human-team-memory-v1 already —
the two most recent runs on the branch, including at a9e20df, with 8
runtime.maintenanceMs.* violations and assetViolations: []. Those are graph
and wiki index maintenance timings; this branch touches drift reading and
grounding capture, not indexing. Not addressed here, and deliberately not
worked around: widening a budget is the same move as raising a timeout.

Scope left out

There is no shipped command that only captures baselines — the backfill is
reachable only through mex graph ground, mex sync or mex setup, each of
which launches an agent or is scoped to a new scaffold. For an existing scaffold
whose groundings are correct and merely lack a hash, there is no way to ask for
the one thing needed. Recorded rather than fixed; a new command surface was out
of scope.