Hold a read that has nothing yet and answer it when its file has news

A following log, event, pty/data or a pty/run before its answer used to
answer .again and wait for a wakeAll, which only the parked-write path
asked for, so the band-aid had every queue push set turn.parked. Now the
core keeps such a read (ctlfs.hold) and, as the turn is given up after
anything that queued a record, ran a command out or closed a pane,
answers it on its own connection, the way factotum answers the log reads
it keeps and acme an event read. Only a read the engine still holds
parked is answered, because cloud9 tells the backend nothing of a
Tflush, so a flushed read spends no record.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

2 files changed, 16 insertions, 2 deletions

diff --git a/docs/cloud9.md b/docs/cloud9.md
index 6eb76238..8d4b6b44 100644
--- a/docs/cloud9.md
+++ b/docs/cloud9.md
@@ -21,7 +21,11 @@ turn with the core (`pardes.turn`) while the editor waits for input or is out
 in a syscall. A request that would change a pane while the editor is mid-step
 is parked with `Status.again` -- the engine parks reads, writes, opens,
 truncations, clunks and removes -- and retried by `Runner.wakeAll` when the
-editor next rests. `src/9p_quic.zig` selects the existing `pardes-9p` ALPN for
+editor next rests. A read with nothing yet parks the same way, but is never
+retried for news: the core holds it (`ctlfs.hold`) and `answerHeld` answers
+it on its connection through `Conn.reply`'s engine, under the connection's
+lock and only while the engine still holds that tag parked, since cloud9 does
+not tell the backend about a Tflush. `src/9p_quic.zig` selects the existing `pardes-9p` ALPN for
 cloud9's optional OpenSSL transport; QUIC still runs on the poll loop in
 `src/9p_io.zig` on the editor's thread, since cloud9's QUIC adapter is
 nonblocking-descriptor based rather than `std.Io` based.
diff --git a/docs/fs.md b/docs/fs.md
index 90849a58..0d6ffcda 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -192,10 +192,20 @@ pane is being made can precede that pane's `new`; panes present at boot are
 recorded before anything else.
 Control characters in a record become spaces, so a record is one line. An
 open freezes the ring's text the way `/screen` freezes a frame: reads walk it
-and end. Writing `follow` to that same open makes reads past it park for the
+and end. Writing `follow` to that same open makes reads past it wait for the
 next record, one per read; a follower the ring outran reads `lost N` first.
 Closing the open is the only way back, as with rio's `consctl`.
 
+A read with nothing to give yet -- a following `log`, `event`, `pty/data`, a
+`pty/run` before its answer -- is held, the way factotum holds its log's reads
+(security/auth/factotum/log.c) and acme an event read: the core keeps it, and
+whoever next has news for it (a record, output, a run's answer, the pane
+closing, which answers "No such file or directory") answers it on the connection it
+came on as the turn is given up. Nothing else parked is retried for it. A
+read the client flushed meanwhile is dropped unanswered, so no record is
+spent on it. An open waits with one read at a time, as acme's window keeps
+one `eventx`. QUIC connections still retry their parked reads each tick.
+
 `pty/run` runs one line at a terminal's prompt and answers how it ended, on
 the same open (factotum's `rpc` shape): write the line, then read `exit N`
 once the command has ended and the shell is back at a prompt, followed by