chat: ctrl+enter queues a follow-up, and a click takes a queued message back

[ZeroPoint95]

TL;DR: ctrl+enter queues a message for after the turn. Each queued message gets its own dim ↳ row above the box, and clicking a row takes it back.

---

Added

• Click to unqueue. Click a queued row and that message comes out of the session's queue and back into the box, pasted documents included.
  • The row lights under the pointer, which is the only hint. It lights only where a click would actually work.
  • If the turn already started it, the row stays and the message runs.
• The take-back works over the wire too. New MethodUnqueueFollowUp (client and server). An older engine just answers "no", so the row stays put.
• New icon slot GFollowUp (↳). It shares the reply arrow's character, told apart by position, and that argument is recorded in TestOneGlyphOneMeaning.

Changed

• Queue key: ctrl+q → ctrl+enter. ctrl+q is now unbound on purpose.
  • It only works where the terminal can tell ctrl+enter from enter. Elsewhere it stays a newline.
  • Words only. With a picture (or a picked harness) on the tray it refuses in one line (ctrl+enter queues words alone — …) and changes nothing. The foot doesn't offer it then either.
• The queue is shown message by message. It used to be one count, after yield · N.
• The foot while a turn runs: enter steers it in · ctrl+enter queue · esc interrupt.
  • ctrl+enter queue takes the slot ctrl+shift+enter stops and sends used to have.
  • ctrl+shift+enter still works and is still on the ? sheet.
• Standing orders: ctrl+enter no longer marks a draft as a rule. Use /standing <words>.

Fixed

• The click did nothing on a normal (hosted) launch. countingAgent (the telemetry tee in cmd/codeaf) handed the surface a copy of each queued stream, so the take-back named a stream the engine never minted and always got false.
  • The tee now maps each copy back to the original stream.
  • New test over the real loopback wire: fails without the fix, passes with it.

Removed

• The dim line under the queue (queued for after this turn · click takes one back · ctrl+enter queues the draft).
• ↑ never reaches the queue. It stays the key for the parked block and history.

Manual and docs

• keys.md, screen.md, hints-and-tips.md, standing-orders.md, the icon design doc and the change entry all say what the code does now.

Checked

• make pr-ready: laws, manual and internal/tui3 all pass.
• ⚠️ Six tests are red, and red on clean dev too (checked in a detached worktree at origin/dev). Not caused by this branch:
  • cmd/codeaf: TestDoOnTheRunEngine… ×4 (/private/var vs /var path mismatch)
  • internal/session: TestNewAdmissionReadsSettingsChangedBeforeItsCreation, TestHeldBeltRunStopsWithoutPreparingRepository
• Driven in tmux against a stub model, through a real engine daemon: queue two, click one, it comes back to the box, the other still runs.

Try it

make build && bin/codeaf

Start a turn, type, press ctrl+enter, then click the ↳ row.

🤖 Generated with Claude Code

[AbirAbbas]

Taking over: @ZeroPoint95, I drove this in the real binary on both roads (plain codeaf and codeaf chat --no-host) and pushed fixes for what broke there. The queue, the ↳ rows and the click take-back all work as described. Here is what changed:

• dbba0b531 ctrl+enter queues only when there is a running turn to queue behind; otherwise it is plain enter. Three things went wrong before this. On the new-chat start page (ctrl+t) the words were sent into the conversation under the page. Over /cost with nothing running, the literal text /cost went to the model as a message. And a real ctrl+enter from a modifyOtherKeys terminal (xterm, tmux with extended-keys) was dropped without effect. The chord is now honoured wherever the terminal actually sends it. The foot and the tip still wait for the terminal's key-support reply before they mention it.
• same commit, a take-back never loses words. Clicking a queued row while the box held a draft used to replace the draft, and two quick clicks kept only the last message. Now the message is appended under the draft on a new line, with paste chips renumbered and backspaced-plain slash words kept plain. A row whose take-back is still waiting for the engine's answer is never started, so a turn that ends during the round trip cannot draw the message as sent and then lose it. The words always return to this conversation's composer, even if a task room has the keyboard. Rows this window did not queue (a steer that fell through, or a turn from another window) no longer light up for a click that cannot work. Queued rows wrap to the frame width.
• ec3b71747 remote receipts. A follow-up's take-back receipt now ends with its stream; before, the client never dropped receipts for follow-ups that simply ran. A take-back is now a driver door, honoured only from the connection that queued the message.
• b29009509 merge with feat(chat): chip recognised slash-commands anywhere in the message buffer #1699. The queued message's plain ranges now reach its transcript line. A draft with a live /standing or /task tag takes enter's road instead of being queued as bare words.
• cfd17b563 renames the take-back's settled flag to answered, because that name belongs to the live-state seam law.
• 771f4e66f, 788b5ef26, 260356d51 are dev syncs. Yours resolved enterLine the same way.

Also checked by hand: a dev-build window queues with ctrl+q against an engine from this branch, and this branch's window on an older engine keeps the row while the message still runs.

Left for later, not done here:

• Queued rows have no cap, so ~25 queued messages can push the transcript off a small window.
• Against an older engine (for example --host to a machine on an older codeaf), rows still light under the pointer even though the click does nothing.
• Clicking a parked (enter-held) row still replaces a draft in the box. That predates this PR.
• With ctrl+q unbound, a terminal that cannot send ctrl+enter has no queue key at all. The manual says so.

[AbirAbbas]

Synced with dev (#1662, #1730), now at 63b5fbbfc, CI green. On the new-chat page, ctrl+enter now goes through #1662's background open like enter, and pressing it again while the chat opens does nothing, the same as a second enter. On home, ctrl+enter still asks here, as before. Checked by hand on the rebuilt binary.

[AbirAbbas]

Verified by hand on both roads and across old/new engine builds: ctrl+enter queues mid-turn, a click takes a queued message back under the draft, and plain tags stay plain. Merging.