Hand the window to a REPL, so the UI is something to poke at

glimmer-vidya could be run and it could be tested, but there was no way
to hold a running window still and change it. `jolt counter` recompiles
the component every time you want a different one, which is the loop this
toolkit exists to avoid.

`jolt repl-ui` is that window. Its whole contents are one ratom and a
prompt that writes to it — nothing in the arrangement is special to
REPLs, only the cell is driven by what you type rather than by a handler.
Hiccup is fixed at the moment you type it; a zero-arg function is mounted
as a component and re-runs whenever a cell it derefs changes, so
`(show! (fn [] [:label {:label (str "hits " @hits)}]))` follows a later
`(swap! hits inc)`. Either way the reconciler patches what changed, and
an `:entry` keeps its text and cursor across a `show!`.

Two boundary rules shaped it, both the library's rather than glimmer's.

The frame loop must own the main thread — winit will not create an event
loop anywhere else — so `-main` paints on the main thread and reads stdin
on a second one. From an editor it is the other way around: `jolt
nrepl-server` parks the main thread in a pump, and `start!` posts the
loop to it through `jolt.host/call-on-main-thread`, leaving eval free. An
event loop cannot be recreated either, so `stop!` ends the window for the
life of that process and `start!` says so rather than opening an
invisible one.

Nodes belong to the loop thread. `show!` is safe from anywhere because a
ratom is not a node, but the library keeps its arena in thread-local
storage, so anything that reads or writes the tree has to hop — which is
what `gui` does with `glimmer.core/on-gui`, and why `dump!` returns the
tree rather than an empty root. It waits on a promise by polling, because
`glimmer.ratom` replaces `deref` with a cell-aware one-arity version and
the timeout arity is not there to call.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>