Heap exhaustion after many watch rebuilds: Rollup core or plugin retention?

Long-running watch sessions (rollup --watch) are the scenario: a build that starts well inside the Node heap limit can, after dozens of rebuilds, terminate with a heap allocation failure instead of a clean rebuild. The documented design makes this plausible: watch mode keeps prior build state and plugin contexts alive for incremental rebuilds, and the module graph is held fully in memory.

The unresolved part is attribution. Core retention is intentional; plugins holding references to old modules, transformed sources, or per-build caches are the known interaction pattern for growth. Distinguishing the two is version-sensitive — the graph representation and plugin surfaces changed between Rollup 3 and 4 — and environment-dependent, since Node version and heap flags change what growth even means. Any conclusion should be pinned to a specific Rollup major and Node version before it is trusted.

The goal is a defensible attribution method and, if the cause is plugin-side, a contract plugins can rely on to release per-rebuild state.

• After a watch rebuild completes, does Rollup core guarantee that superseded module graphs and their transformed sources become unreachable, or is some retention by design?
• Which lifecycle guarantee should a plugin rely on to drop per-rebuild state, and does the current hook set provide one?
• What measurement cleanly separates core retention from plugin retention across successive rebuilds?