bug: diff cache corruption when working tree reads cache written by git-ref side

[rocketman-code]

Current Behavior

When running chainsaw diff <ref> --entry <file>, the git-ref side writes a reduced graph (no node_modules) to the disk cache. The working-tree side then reads that contaminated cache entry, producing incorrect results. Subsequent chainsaw trace commands also read the corrupted cache.

Expected Behavior

The working-tree side of a diff should not read or write the disk cache. Each side should build its graph independently to avoid cross-contamination.

Context

This is a data corruption bug that silently produces wrong results. Users running diff could corrupt their cache for all subsequent commands until the cache is manually cleared.

Technical Details

Relevant Code

src/main.rs — build_snapshot_from_working_tree

The function called loader::load_graph(entry, false) (no_cache=false), allowing it to read/write cache. The git-ref side writes a smaller graph to cache first, then the working tree side reads that stale entry.

Reproduction

1. Run chainsaw diff HEAD~1 --entry src/index.ts
2. Run chainsaw trace src/index.ts immediately after
3. Observe that the trace result may be incorrect due to the cached graph from the diff's git-ref side

[rocketman-code]

Fixed in 2ea1fe6 — build_snapshot_from_working_tree now passes no_cache=true to loader::load_graph, preventing the working-tree side from reading or overwriting the disk cache during diff operations.