tui: leaks ~21MB .so per launch into /tmp; fills tmpfs and breaks TUI startup

Summary

The TUI leaks a ~21 MB .so file into the temp directory on every launch and never cleans it up. After many launches the temp filesystem fills up, and the TUI then fails to start with an OpenTUI library load error.

Environment

• opencode version: 0.0.0-next-17444
• OS: Arch Linux, kernel 7.1.3-arch2-2 (linux x64)
• Terminal: xterm-256color (also reproduced over SSH from a phone terminal)
• Shell: /usr/bin/bash
• Install/channel: next (npm global install)
• Active plugins: none active; config lists a local skill plugin (ponytail.mjs) and a local plugin (caveman/plugin.js) — unrelated to this failure, TUI fails with plugins disabled too

Reproduction

1. Run opencode2 (TUI) in a terminal, exit it. Repeat the launch several times (each launch generates a fresh extraction).
2. Check the temp directory: ls -la /tmp | grep '\.so$' — each launch adds a file like .39dbfbfdbf6bfbff-00000000.so (~21 MB, random hash prefix per launch). 2,338 files / ~13 GB accumulated over days of normal use on this machine.
3. Once the temp filesystem is full, the TUI fails at startup:

ERROR (#1): Error: Failed to initialize OpenTUI render library: Failed to open library "/$bunfs/root/libopentui-6wc2mm41.so": /$bunfs/root/libopentui-6wc2mm41.so: cannot open shared object file
    at Y0 (../../node_modules/.bun/@opentui+core@0.5.3+2240c214a0f33214/node_modules/@opentui/core/chunk-bun-26r5c5w5.js:17303:17)
    at new F8 (.../node_modules/.bun/@opentui+core@0.5.3+2240c214a0f33214/node_modules/@opentui/core/chunk-bun-t68f2fmr.js:7236:17)

Expected Behavior

The extracted library file is either reused across launches (stable name / extracted once) or removed when the TUI exits. The temp directory should not grow unboundedly.

Actual Behavior

Every TUI launch extracts a fresh hashed .so (~21 MB) into $TMPDIR (default /tmp) and leaves it there. On this machine the files accumulated to ~13 GB, filling the tmpfs and causing the startup failure above. Clearing /tmp/.[0-9a-f]*-*.so restores normal operation (2,338 files deleted, 13 GB reclaimed). Other processes doing large tmpfs writes (Gradle/Kotlin daemons, build tools) make the failure arrive sooner.

Additional Context

• Workaround: rm /tmp/.[0-9a-f]*-*.so (safe — the running TUI keeps the loaded library mapped; a daily cron purge was installed to keep the box usable).
• The hashed names match bun's embedded-filesystem extraction pattern (bunfs), so this likely affects any bun-compiled binary that extracts libraries into the temp dir without cleanup.
• Frequency: every launch; the failure itself appears once the temp filesystem is full, which took ~2 days of frequent TUI use here.