Design: hosting interactive Textual widgets per entry (widget overlay)

[tya5]

Context

The entry view is a rich.console.RenderableType, so display components
reuse cleanly today: Panel/Table/Syntax/Markdown and the built-in
indicators rich.spinner.Spinner / rich.progress_bar.ProgressBar drop
straight into a Presentation (see examples/progress.py). Light interaction
is covered by FlowView.Clicked hit-testing (see examples/intervention.py).

What is not covered: mounting real interactive Textual widgets
(Button, Select, Input) as an entry's body — FlowView paints renderables
to strips (that is what makes variable-height virtualization cheap) and does not
mount a child widget per row.

Decision needed

Do we add a way to host real Textual widgets for entries, and if so, how far?

Option A — don't (recommended default).
Keep the paint model. Interactivity via Clicked hit-testing + Rich
renderables. Matches how Textual's own OptionList/DataTable work (they paint
lines, no per-row widgets). Zero core risk.

Option B — bounded "active overlay".
Opt-in: an entry can host ONE real Textual widget, mounted as an overlay
positioned over its region only while visible, unmounted on scroll-away /
resolve. Gives real Button/Select/Input for the few entries that need it
(e.g. an intervention prompt) without mounting thousands. Cost: mount/position/
unmount lifecycle, scroll tracking, focus handling, state loss on unmount.

Option C — full per-entry widgets.
Rejected: defeats virtualization; mounting/unmounting on scroll is expensive and
loses state/focus.

Recommendation

Ship A now (already effectively done). Build B only when a concrete use case
needs true focus/keyboard interaction inside the flow, and keep it strictly
opt-in so the core paint path is untouched.

[tya5]

Refinement: Option B is narrower than it first looked

Scalability note for an OSS widget: N is not ours to choose, so the core must
stay paint-based (O(viewport)) — mounting all entries (even hidden) is O(N) and
doesn't scale; mounting the visible band needs a recycling pool + async-layout
height handling and still janks. Confirmed by Textual's own scrollables
(OptionList/DataTable/RichLog) all painting rather than mounting per row.

Key realization: a single interactive widget (e.g. a chat composer) has no
reason to live inside FlowView at all — dock it outside as a normal Textual
widget (the reyn PoC already docks a Composer TextArea at the bottom).

So Option B (in-flow real-widget overlay) is only justified when a real
interactive widget must be anchored inline to a specific scrolling entry —
e.g. an inline reply/edit box that scrolls with its message. If the interaction
doesn't need to track a scroll position, dock it outside; if it's a light
in-flow control (option chips, buttons), paint it and hit-test FlowView.Clicked.

Decision: keep the core paint-only (Option A). Do NOT build the visible-band or
mount-all approaches. Build the O(1) overlay (Option B) only if a concrete
inline-anchored-widget need appears — otherwise it's unnecessary.

[tya5]

Decision: adopt Option A for now — the paint model + Clicked hit-testing + Rich renderables cover display and light interaction, matching how Textual's own OptionList/DataTable work. Keeping this open as the tracking issue for Option B (bounded opt-in active overlay), to be built only when a concrete case needs true focus/keyboard interaction inside the flow. No core changes until then.