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]>

1 files changed, 5 insertions, 1 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.