Fixes from three adversarial reviews, and a destructive one among them

The registry sweep could delete a live socket, anywhere on the filesystem. A
reviewer reproduced it: a socket that is bound but has not reached listen(2)
answers ECONNREFUSED exactly like a dead one -- that window is every server's
startup -- and the sweep then followed the entry's symlink and unlinked
whatever absolute path it named. It now follows a target only into the
directory our own sockets live in and only to a `pardes-9p-*.sock` name, it
re-probes immediately before deleting rather than trusting a probe that is by
then several syscalls old, and a readlink that exactly filled its buffer is
treated as the truncation it is. The test grew a case for an entry whose
target is not ours: the entry goes, the file does not.

Ctrl-V in raw tty mode was a black hole when the yank register was empty --
neither typed nor forwarded -- so vim's visual block, readline's quoted-insert
and every other program's Ctrl-V simply vanished. With nothing to paste the
chord belongs to the program again.

The lone-ESC flush added earlier was dead code. vaxis already returns Escape
for a one-byte 0x1b (`Parser.parseGround` asserts `input.len == 1`), so the
carried byte it waited for can never exist; a reviewer showed a 3 ms gap and a
60 ms gap behaving identically. Removed rather than left to imply a guarantee
it never provided.

A shell whose editor is gone can start one again. Naming a live but
unreachable session made `pardes <file>` exit 1, which let a stale environment
variable lock someone out of their own editor; it falls through to an ordinary
session, as it did before the variable existed.

Also: the macOS ABI check for `pardes_topbar_pane_border_px` had been replaced
by a duplicate of the line above it; `--startup` now fails on a leak the way
every other measurement in that file does, and stops calling its maximum a p95
below twenty samples; the served README and the skill no longer tell you to
write to `data` with `>`, which truncates the whole body before the write
lands; `docs/v9fs.md` described the allocate-on-walk design that was rejected;
and `test/fs.py` keys nesting off `PARDES_PID`, so its forwarding case stops
passing only when the runner happens to be inside a live pardes.

fs-test now reaches its one documented pre-existing failure instead of dying
early. Suite 778/783 with the two known crashes.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

1 files changed, 7 insertions, 9 deletions

diff --git a/docs/v9fs.md b/docs/v9fs.md
index 1b14c21f..cfbbd35b 100644
--- a/docs/v9fs.md
+++ b/docs/v9fs.md
@@ -13,16 +13,14 @@ cat "$PARDES_MOUNT/index"
 cat "$PARDES_MOUNT/README"
 cat "$PARDES_MOUNT/pane/$PARDES_PANE/body"
 echo 'Msg hello' > "$PARDES_MOUNT/exec"
-awk '{print $1}' "$PARDES_MOUNT/pane/new/ctl"
+n=$(cat "$PARDES_MOUNT/pane/new")
 ```
 
-Walking to `pane/new` opens a pane, and the walk lands on that pane's own
-directory, so its `ctl` answers the serial to use afterwards. The kernel keeps
-the name it walked rather than the one the server answers back, so
-`pane/new` stays in the dentry cache as a name of its own; address the pane as
-`pane/<serial>` once you have it, and expect a fresh path resolution of
-`pane/new` to open another pane. It is not listed in `pane/`, so `ls -l` and
-`find` over the mount create nothing.
+**Opening** `pane/new` makes a pane, and reading that open file answers its
+serial; address the pane as `pane/<serial>` from then on. Each open makes
+another one, so read it once and keep the number. A *stat* makes nothing,
+which is why `new` can be listed at all: `ls`, `ls -l` and `find` over the
+whole mount create nothing, because none of them open it.
 
 The mount belongs to that pane's subprocess tree. Other panes and the editor
 core keep their original mount namespace. It works in native Linux TTY and SDL
@@ -112,5 +110,5 @@ Pardes accepts this truncation without storing caller-selected timestamps;
 standalone timestamp, permission, and ownership changes remain unsupported.
 
 The initial kernel probe passed on this host on 2026-09-14. The broader
-`fs-test` has an existing syntax-bold assertion failure at `test/fs.py:459`,
+`fs-test` has an existing syntax-bold assertion failure (now `test/fs.py:615`),
 also reproduced on the cached editor binary preceding the truncation fix.