#1196 Views: cut the call-graph view build's peak memory by about 70%

With views on, building a checkout's call-graph view peaked at about 6.5 GB on a large project. This cuts the peak by about 70% with identical stored rows.

Where the memory went. A dependency-free test allocator with phase attribution (test-only, never compiled into AFT) measured the peak first: about 1.10 GB in parsed extracts held for the whole join, 0.94 GB in cloned reference work, and 0.46 GB in decoded objects held twice. Lookup-map construction was only about 47 MB.

What changed.

• Binding and resolution run one caller at a time instead of over the whole cloned reference set.
• Encoded reconciliation payloads are retired once used, under the live pins that already protect them.
• Decoded objects are shared through weak references, including on the v3 reader path, so the reader never pins what it has emitted.
• The materialization join no longer builds a second copy of the resolution order that the SQL write never reads.
• Cold reference and edge emission is batched, and graph inputs are released before dispatch.

Stored schemas, producer keys and materialization versions are unchanged.

Measured on one Linux 12-vCPU allocation, same probe and corpus for both builds (6,832 tracked paths): peak RSS 6,462 MiB → 1,937 MiB (−70%); wall 768 s → 574 s; CPU 599 s → 566 s. All 3,746,437 rows across the 20 derived tables match exactly. These are single-pair unoptimized test measurements on shared hardware.

Tests. Row-for-row parity for decode-once materialization, for batched versus unbatched emission past the 4,096-reference batch boundary, and for the join without the duplicate resolution order. The reader no longer pins emitted blobs. The existing 384 MiB fixed-fixture memory guard is unchanged: it fails on the old code (1,263,020 KiB) and passes now.

Views are off by default, so there is no user-facing change and no release note. Verified after merging current main: 210 view, materialization and call-graph join library tests, formatting, and the Windows compile check.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Cuts the call-graph view build's peak memory by about 70% with views enabled, producing identical stored rows.

• Binding and resolution stream one caller at a time instead of holding every parsed extract and cloned reference for the whole join.
• Reconciliation payloads are retired once the live pins protect them; decoded blobs are shared through weak references so the reader never pins what it has emitted.
• Cold reference and edge emission is batched, graph inputs are released before dispatch, and the join no longer builds the resolution-order copy that the SQL write never reads.

Measured on the same probe: peak RSS 6,462 MiB → 1,937 MiB (−70%), wall 768 s → 574 s, and all 3,746,437 rows across the 20 derived tables match exactly. Stored schemas, producer keys, and materialization versions are unchanged. Views are off by default, so there is no user-facing change.

Tests cover row parity for decode-once materialization, batched versus unbatched emission past the 4,096-reference boundary, and the join without the duplicate resolution order; the fixed 384 MiB fixture memory guard fails on the old code and passes now.