A listing freezes at its open, so a read in several chunks never splices two moments

/index and the other listings were rendered afresh for each read, so a client reading one in chunks while panes changed got rows from two moments spliced together (the fs-test flake). /index, /layout, /recent, /commands, /status, /listeners and a ctl opened only to read now freeze at the open, as /screen does.

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

1 files changed, 5 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 337996fd..c72c0131 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -1034,8 +1034,11 @@ terminal `body` freezes its history on the first read of each open handle;
 a PDF's `body` reads the text layer of the page it shows (MuPDF's
 extraction; turn the page for another), and it, as an image's, takes no
 write (`this pane has no text`, EINVAL);
-`pty/data` streams live output. An open that holds something between open
-and close -- a frozen screen, terminal body or log, a run, an `event` or
+`pty/data` streams live output. The listings -- `/index`, `/layout`,
+`/recent`, `/commands`, `/status`, `/listeners`, and a `ctl` opened only to
+read -- freeze at the open too, so one read in several chunks never splices
+two moments; open again for what is there now. An open that holds something between open
+and close -- a frozen screen, listing, terminal body or log, a run, an `event` or
 `pty/data` open -- takes one of 64 records (lib9p's per-fid aux, acme's
 Fid), released on close or disconnect; past that such an open fails with
 `ENFILE`. Other opens hold nothing and are not counted.