Fixes #234393. The crash dumps, heap snapshots, and retainer chains referenced below are in #307156, which was closed as a duplicate of it.

Problem

The main process accumulates all terminal PTY output in the V8 heap until it hits the ~4 GB heap ceiling and OOM-aborts (Reached heap limit). Heavy ANSI producers in the integrated terminal (tmux status/pane redraws, TUI apps) crash the main process within hours; median ~4.2h across the 99 crash dumps in #307156.

Root cause

ProxyChannel.fromService eagerly wraps every service event in Event.buffer(..., flushAfterTimeout=true), which subscribes to the source immediately and queues each event into an array that is only flushed (and released) when a first listener attaches to the channel event.

The main process registers ILocalPtyService this way (app.ts) as the TerminalIpcChannels.LocalPty channel. On desktop, the renderer consumes terminal data over the dedicated pty host connection (PtyHostWindow MessagePort, see localTerminalBackend.ts); the LocalPty channel itself is only used for two method calls (getLatency, getProfiles) plus a handful of low-frequency pty-host lifecycle events (onPtyHostStart/onPtyHostExit/onPtyHostUnresponsive/onPtyHostResponsive/onPtyHostRequestResolveVariables, consumed by BaseTerminalBackend) — it never gets a listener for the high-volume onProcessData event. So the eager buffer for onProcessData (one entry per PTY data chunk) grows for the lifetime of the process. Retainer chains in heap snapshots (see #307156) show ~99% of the heap held by exactly this array: Emitter._listeners → closure → Array[N] → { event: }.

Fix

Adds a disableEventBuffering option to ProxyChannel.ICreateServiceChannelOptions (naming follows the existing disableMarshalling) that exposes service events on the channel without the eager Event.buffer wrapper, and applies it to the LocalPty channel registration. Events fired before a listener attaches are dropped instead of retained. This is a whole-channel opt-out, so it also stops buffering the pty-host lifecycle events BaseTerminalBackend listens to here; in practice that's low-risk (those fire only after a window's listener has attached, and the one early-fireable case — the initial onPtyHostStart — is a no-op per BaseTerminalBackend's own hasStarted guard, see review discussion below). Per Dmitriy Vasyura (@dmitrivMS)'s plan, this PR ships as the accepted stop-gap; a follow-up telemetry pass will confirm whether any channel actually needs buffering restored before removing it from fromService generally.

Testing

• New unit tests in ipc.test.ts cover the default (eager subscription, buffered) and the new option (no subscription until listen, events delivered after).
• Full node unit suite passes (11,908 passing).
• A/B with the repro from the issue (ANSI-flood script in the integrated terminal, fresh profile, --disable-extensions, macOS arm64), measuring main-process RSS every 15 s on the same dev build with only this change toggled: