fix: resolve trace and chain hashes without rescanning the store

[creatornader]

What was actually wrong

The deploy-services canary flap was a real production outage, not an impatient check.

/v1/trace and /v1/chain resolved a record_hash by rebuilding an index over the entire store on every request: getAllRecords() then canonicalRecord -> sha256 -> hexEncode for every record. The code said why that was fine:

For a busy log this would move into the store, but at current scale (low thousands of records) the per-request build is fast enough.

The log passed 112k records in July 2026, two orders of magnitude past that assumption.

Evidence

Three consecutive /v1/trace requests against production, 2026-07-29:

attempt1 status=502 total=17.474184s
attempt2 status=502 total=25.695895s
attempt3 status=502 total=24.675035s

Each one crashed the service. From flyctl logs -a atrib-graph:

Mark-Compact (reduce) 479.3 (488.5) -> 479.2 (488.5) MB, (average mu = 0.351)
FATAL ERROR: Ineffective mark-compacts near heap limit
Main child exited with signal (with signal 'SIGABRT', core dumped? false)

Mark-compact reclaiming 0.1MB of a 488MB heap, and mu = 0.35 means 65% of wall-clock in GC. The live set had filled the heap. Measured cost of one rebuild at this size: ~80MB of transient strings and >1s of CPU.

Each crash then replayed the 68MB archive (6s cold, up to 74s under pressure), extending the 502 window. The canary polls every 2s but each attempt blocked 17-25s, which is why it reported only 3-4 attempts inside its 90s deadline and exited with last_status=502.

Ruled out along the way:

• Not the triggering commit. faf69bc0 both succeeded (02:14) and failed (02:19).
• Not a deploy race. apps/dashboard/* maps to log_node only, so those runs never deployed graph-node.
• Not an impatient canary. The loop is deadline-bound (90s), not attempt-bound. The low attempt count is a symptom of 20s+ hangs, not a cause.

The fix

1. O(1) hash resolution. The store already hashes every record once at ingest and exposes getRecordByHash(). Both handlers now use it. Same semantics: the walks only ever did point lookups.

2. Let V8 use the RAM the machine already has. Node caps old-space near half a small machine's RAM regardless of [[vm]] memory. V8 reported heap_size_limit = 493MB on the 1024mb machine, so the 2026-05-06 bump from 256mb never reached the heap that was running out.

The canary is deliberately unchanged. It was correct.

Verification

Real server, 112k records, production's heap margin, identical conditions:

	result
before	FATAL ERROR: Ineffective mark-compacts near heap limit
after	status=200 ms=244

• services/graph-node: 115/115 tests pass, including the §3.4.5 trace and §3.4.6 chain conformance corpora, which pin the semantics.
• New test/trace-hash-lookup.test.ts counts full-store scans and asserts zero. Confirmed to fail on the unfixed code (3 of 5 fail) and pass after.
• pnpm doc-sync: 14 checks pass.

Follow-ups, not in this PR

1. Headroom is finite. The log grows ~4k records/day at ~4KB each in heap, so ~17MB/day. A 768MB heap buys weeks. The durable fix is the disk-backed graph store already flagged in src/persistence.ts, which notes the in-memory shape is sustainable to ~10^5 records. The log passed that.
2. Latent canary race. deploy-log-node and deploy-graph-node both depend only on changes, so they run in parallel with no ordering. A commit touching packages/mcp/* sets both, and the canary can run against a graph-node that is mid-restart. This did not cause the failures investigated here, but it will produce false failures eventually.