tui: support reactive external TSX plugins in packaged CLI

Problem

The packaged Bun CLI does not reliably apply OpenTUI's runtime Solid transform to external TUI plugin TSX. A plugin can either fail while resolving react/jsx-dev-runtime or load project-local solid-js / @opentui/solid copies. The latter renders its initial frame, but signal updates do not repaint because the plugin and host use separate reactive graphs. Imperative renderable mutation works because it bypasses Solid reactivity.

This is specific to dynamically loaded external plugin source in the packaged executable. The same plugin works in source-mode Bun.

Reproduction

1. Run the packaged CLI with an external .opencode/plugins/tui/reactive.tsx plugin.
2. Give the plugin a project-local solid-js and @opentui/solid, as documented for local plugin dependencies.
3. Register a slot that renders a signal and updates it from a timer.
4. Observe either a react/jsx-dev-runtime resolution failure or an initial frame that never repaints.

The reproduction must also cover the supported index.ts -> view.tsx layout, not only a .tsx entrypoint.

Rejected approach

PR #39983 attempted to precompile external JSX with Bun.build and map selected Solid/OpenTUI imports to the host runtime. We closed it because runtime bundling changed plugin module semantics and still missed supported shapes:

• .ts and .js entrypoints importing TSX bypassed preparation.
• Bundling relocated import.meta.url, breaking plugin-relative assets, workers, WASM, and dynamic imports.
• OpenTUI's transform excludes JSX under node_modules, so npm TSX could still fail.
• Package-prefix externalization could leave unsupported solid-js/* imports unresolved or load another runtime.
• Cache identity used only entrypoint mtime despite embedding the full dependency graph.
• The persistent generated-bundle cache was unbounded and shared across processes.
• Tests invoked the preparation helper directly rather than exercising the packaged executable.

Do not revive graph-wide runtime bundling without resolving those compatibility constraints.

Plan

1. Keep a minimal packaged-CLI regression fixture that proves a signal update visibly repaints.
2. Cover both a direct .tsx entrypoint and a .ts entrypoint importing .tsx.
3. Run the fixture against Bun 1.4/canary, where related runtime onLoad fixes have landed.
4. If the newer Bun runtime fixes the reproduction, upgrade when a suitable release is available.
5. Otherwise reduce it to an OpenTUI reproduction and add an OpenTUI-owned external-module loading API or upstream fix. OpenTUI should own its runtime module registry and transform contract.
6. Keep OpenCode loading plugins as modules. Do not bundle arbitrary third-party dependency graphs into the OpenCode state directory.

Acceptance criteria

• Reactive external TSX visibly repaints in the packaged CLI.
• .ts -> .tsx plugin graphs work.
• Plugin and host share the required Solid/OpenTUI singleton modules.
• Ordinary dependencies retain normal module identity and resolution behavior.
• Plugin-relative assets and import.meta.url retain their original meaning.
• The regression runs against the packaged artifact, not only source-mode Bun.

Start with the minimal packaged-CLI regression fixture and run it against Bun 1.4/canary, covering both a direct .tsx entrypoint and an index.ts -> view.tsx layout. Done means the packaged artifact visibly repaints reactive external TSX, shares the required Solid/OpenTUI singletons, and preserves normal dependency resolution and plugin-relative asset behavior.