AST cache replays node ids minted under the original root after a corpus move/clone

[safishamsi]

Surfaced while closing the node-id leak class (#2231/#2243). Distinct vector, own issue.

Problem. The per-file AST cache stores extracted nodes/edges keyed by content + relative path (namespaced by extractor version). When the same corpus is reached under a different absolute root (a clone, a moved checkout, a second mount) and the cache is carried along, a warm cache hit replays nodes/edges whose ids were minted from the ORIGINAL absolute root. The id-remap / final-canonicalization passes in extract() cannot fix these, because those ids no longer match any current-path form (the current run never sees the original root), so a stale machine-slug id can survive into graph.json on a cache hit.

This is separate from #2231/#2243 (which fix producers on a cold run) and from #2199 (stat-index portability, already fixed) — it's the AST result cache replaying pre-canonicalization ids.

Fix direction. Canonicalize node ids / edge endpoints when replaying a cached entry (re-anchor any id/endpoint minted from the entry's stored absolute source_file to the current root), or store cache entries already canonicalized (root-relative ids) so a replay is portable by construction. Mirror the manifest.json / stat-index.json portability approach (#2199).

Test. Extract a corpus under root A (populate cache), copy the tree + graphify-out to root B, extract under B with the warm cache, assert no node id / edge endpoint contains the root-A slug and ids match a cold B extraction.

[Kaushik2003]

@safishamsi — short version of what I did.

The AST cache stores each file's nodes/edges exactly as the extractor made them, and extractors build ids from the path string they get. So an entry written under one root has that root's slug baked into every id. On a warm hit under a different root (clone, moved checkout), extract()'s id-remap can't fix those ids because it only knows the current paths — so the old root's slug ends up in graph.json.

Fix: cache entries now store the root as a $graphify-root$ placeholder and swap the current root back in on read. Same idea already used for source_file (#777) and the stat index (#2199). The loaded entry ends up identical to what a fresh extraction would produce, so nothing outside cache.py had to change.

I reproduced the bug first, then fixed it. The regression test extracts a corpus at root A, copies it plus graphify-out/ to root B, extracts at B on the warm cache, and checks no A slug is left and the ids match a cold B run. Full suite passes (3787). Also checked it on graphify's own tree — 334 files, warm graph identical to cold.

One thing on your side: old cache entries have no placeholder and their content hash never changes, so they can't fix themselves. They get cleared when the version bumps, since AST entries live under cache/ast/v{version}/.

Happy to change anything if you'd prefer a different approach.