feat(tui): add persistent terminal panes

[jlongster]

Summary

This PR adds persistent, multi-client terminal workspaces to the V2 TUI.

Persistent PTY backend

• add persistent terminal and ordered group schemas, events, and Core services
• bridge OpenCode to the companion opencode-pty sidecar, including stale-registration recovery
• expose group, terminal, snapshot, lifecycle, and WebSocket attachment APIs
• preserve ordered input, authoritative replay/checkpoints, resize synchronization, controller takeover, and observer delivery
• stop the sidecar only for explicit service stop/restart, not automatic replacement or update paths

TUI pane workspaces

• add client-local BSP pane geometry while synchronizing group membership through the server
• render sessions and persistent terminals as sibling pane items
• restore terminal state from authoritative snapshots and ordered output
• add /terminal and terminal-workspace entry points
• persist pane layouts and active tabs across TUI restarts
• add pane focus styling, headers, theme-derived terminal colors, selection, and click-to-focus behavior

Development support

• add simulation screenshot support used by OpenCode Drive
• add a temporary fixed-state Drive reproduction script for pane styling
• regenerate Promise and Effect clients for the new API

Companion implementations

This branch expects:

• opencode-pty protocol v4 for durable PTYs, checkpoints, replay, controller/observer roles, and bounded subscriber delivery
• the companion OpenTUI embedded-terminal implementation for VT rendering, selection, input encoding, and composition

The sidecar and OpenTUI changes are not contained in this repository.

Review notes

The temporary active-tab restoration, screenshot support, and script/drive-pane-style.sh were added to make the pane UI reproducible during styling and are explicitly marked for removal or extraction before the feature is finalized.

Verification

Previously exercised against the companion release sidecar with:

• package typechecks across Core, Protocol, Client, Server, CLI, and TUI
• focused Schema, Core group, TUI pane/tab, and real two-client persistent PTY integration tests
• sidecar test suite and Clippy

After rebasing onto current v2:

• regenerated all client surfaces
• refreshed bun.lock
• verified origin/v2 is an ancestor
• verified git diff --check origin/v2...HEAD

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Scope: draft — persistent terminal panes: a new PersistentPty core service that talks to an external opencode-pty sidecar daemon (protocol v4, companion Rust runtime in a separate repo) over a Unix socket with token auth, plus TUI pane workspace/layout components, server handlers with short-lived connect tickets, and regenerated client surfaces.

• The durability design is coherent: terminals outlive the opencode process via a detached daemon; authoritative snapshots + resize checkpoints + offset-based replay give multi-client consistency; controller delivery is lossless while observers get bounded delivery — the right trade-off, and stale sidecar registrations are recovered rather than trusted.
• Security layering is mostly sound (per-uid runtime dir keyed by hashed DB path, token-on-first-frame over the socket, ping validation of instance_id/pid/protocol before reuse, 8MB frame cap). Please clarify the constant-header check in the server handler: rejecting requests whose PTY_CONNECT_TOKEN_HEADER doesn't equal a compile-time constant value is not authentication by itself — confirm real authorization flows through the session auth + short-lived ticket, and document what that header actually defends against.
• Operational questions a maintainer will want answered before this leaves draft:
  • Orphan lifecycle: the daemon is spawned detached/unref'd and intentionally survives service restarts; only explicit stop/restart tears it down. What's the user-facing story for "why is there an opencode-pty process running" / cleanup after uninstall?
  • Portability: net.createConnection(registration.socket) assumes AF_UNIX; Windows needs a named-pipe path or an explicit unsupported-platform gate.
  • Cross-repo coupling: merging requires a released protocol-v4 sidecar; UnavailableError suggests graceful degradation, but the TUI entry points should be hidden (not just erroring) when the binary is absent.
• Verification hygiene is good: typecheck per package, sidecar tests gated behind OPENCODE_PTY_BIN, cargo test/clippy on the companion, and generated client files regenerated rather than hand-edited.

[jlongster]

This umbrella draft has been split into a clean stack rebased on current v2:

1. feat(core): add persistent terminal groups #44831 pty-groups: ordered group schemas, events, and persistence
2. feat(server): add persistent PTY daemon API #44832 pty-backend: daemon protocol, server API, generated SDKs, and OpenAPI
3. feat(cli): embed persistent PTY service binaries #44834 pty-binary-assets: verified opencode-pty v0.1.4 embedding and extraction
4. feat(tui): add persistent terminal workspaces #44836 pty-workspaces: persistent terminal workspace UI
5. feat(tui): refine persistent terminal panes #44837 pty-pane-polish: pane layout, focus/keybindings, metadata, and selection polish

Temporary simulation screenshot tooling, Drive repro scripts, and temporary active-tab restoration were intentionally excluded. Review and merge the stack in order.

[jlongster]

The stack was simplified again after review: the generic Group service/schema/API and terminal-only workspaces were removed entirely. The active session-scoped stack is now:

1. feat(server): add persistent PTY daemon API #44969 daemon protocol, session terminal API, and added/removed events
2. feat(cli): embed persistent PTY service binaries #44970 verified native binary embedding/extraction
3. feat(tui): add persistent session terminals #44971 session terminal panes with event-driven reconciliation
4. feat(tui): refine persistent terminal panes #44973 pane focus/layout/selection polish

The superseded group PR and prior stack PRs are closed.