Analysis OOM (exit 137 at ~4 GB) on large TypeScript graphs

Summary

Analyzing a large TypeScript graph OOMs (exit 137) around 4 GB RSS. T3 Code's bin.ts full graph / provider-acp-registry coverage is the evidence; a 4 GB sandbox is not enough for one-shot analysis of that entry.

Expected

Either:

• streaming / incremental analysis that caps per-file type-graph retention, or
• a documented, supported way to compile per-entrypoint with an explicit module list so the full graph is never in memory at once.

The shipping strategy for T3 is per-entrypoint builds regardless (acp-mcp-bridge, acp-mcp-call). Streaming analysis is quality-of-life, not a Phase 0 blocker.

Actual (0.4.7)

scriptc analysis of bin.ts (full server graph) is killed at ~4 GB (exit 137).

Workaround for downstream

Compile per entrypoint. Do not pass the whole server as one program.

Evidence

Plan E7.