Shared Ghostty instance leaks screen-buffer state across Terminals (forces per-terminal WASM load)

[bilby91]

Problem

Creating multiple GhosttyTerminals from a single shared Ghostty instance
(one WASM module instance) leaks screen-buffer state across terminals —
e.g. stale content from one terminal showing up in another, or on reconnect.
The per-terminal handles aren't fully isolated from shared/global state inside
the WASM module.

Current workaround (downstream)

Consumers are forced to call Ghostty.load() per terminal to get a fresh
WASM instance for isolation:

// The shared instance leaks screen buffer data across Terminal instances,
// causing stale content on reconnect.
const ghosttyInstance = await ghostty.Ghostty.load(wasmUrl);  // per terminal
const term = new ghostty.Terminal({ ghostty: ghosttyInstance, ... });

This recompiles/instantiates the ~625 KB WASM for every terminal, which is
wasteful in memory and startup time for apps that open several terminals (or
re-open them across reconnects).

Desired behavior

A single Ghostty.load() should support creating many independent Terminals,
with each terminal's screen buffer / cursor / scrollback fully isolated to its
own handle — so consumers can load the WASM once and cheaply spawn terminals.

Pointers

• Ghostty.load() / createTerminal() in lib/ghostty.ts
• Whatever screen-buffer/render state is module-global vs per-GhosttyTerminal-handle

Impact

Memory + per-terminal startup cost. Not blocking (the per-instance workaround
is correct, just expensive), but fixing it would let multi-terminal apps share
one module instance.