Embeddable TUI crates: make jcode-memory-types optional in jcode-tui-core (or split leaf UI primitives); long-term an embeddable shell without app-core

Context

Genefold/sendzimir-pareto-agent — a single-purpose engineering app (Sendzimir cold-rolling-mill optimisation) built on the pinned jcode submodule — is adopting the workspace-swipe TUI pattern. jcode-tui-workspace (deps: ratatui only) fits perfectly and is already adopted in our plan.

The next layer of reuse is blocked by two hard dependency edges, so today an adopter wanting the shell primitives must either absorb agent surface into its binary or write its own loop:

• jcode-tui-core (useful, generic primitives: keybind, stream_buffer, anchor_stability, copy_selection) hard-depends on jcode-memory-types — the agent memory system's types.
• jcode-tui (the full shell: event loop, input widget, message/log panes) hard-depends on jcode-app-core (server, agent, provider, auth, session, tools).

For a non-agent domain app, neither edge is acceptable: the binary would ship the agent's surface to run a UI.

Requested (two increments, either helps; (1) unblocks near-term, (2) is the real prize)

1. Leaf split / optional feature in jcode-tui-core: move keybind, stream_buffer, anchor_stability (and possibly copy_selection) into a dependency-free leaf crate (e.g. jcode-tui-primitives), or gate jcode-memory-types behind a cargo feature so UI-only adopters compile without it. Nothing else in these modules appears to need memory types — they are pure input/buffer mechanics on crossterm.

2. Embeddable shell crate (longer-term): extract the reusable TUI runtime of jcode-tui — crossterm event loop, alt-screen/raw-mode lifecycle, input-line widget, scrollback/log pane, tick — behind a trait-based seam where the agent feeds messages in, without jcode-app-core. Domain apps (like ours) would then host jcode's actual shell and register their own panes/commands, instead of re-implementing the loop. jcode-tui-workspace already shows this pattern works (a clean crate rendered through a plain function API).

Why upstream

We will not fork: the pinned-submodule model exists so jcode fixes flow by pointer bumps. Filing here per that boundary — the split lets adopters scale their reuse from widget crates to the shell without dragging agent surface, and keeps one jcode lineage.

Happy to contribute the leaf-split PR if the shape sounds right.

Read the jcode-tui-core modules keybind, stream_buffer, anchor_stability, and copy_selection, then inspect how jcode-memory-types enters the crate. Compare the jcode-tui dependency on jcode-app-core and the ratatui-only jcode-tui-workspace pattern. Done means UI primitives or an embeddable shell compile without the agent-specific dependency edges, with the agreed crate or feature boundary documented.