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, 8 insertions, 1 deletions

diff --git a/test/perf.zig b/test/perf.zig
index 8f463204..5ac38ccf 100644
--- a/test/perf.zig
+++ b/test/perf.zig
@@ -200,6 +200,10 @@ fn measureStartup(io: std.Io, reps: usize, json: bool) !void {
                 bytes += counter.bytes;
                 peak = @max(peak, counter.peak);
             }
+            // Every other measurement in this file checks the session gave
+            // everything back; a boot that leaks is exactly what a startup
+            // benchmark should be the first to notice.
+            if (counter.live != 0) return error.LeakedStartupMemory;
         }
         std.mem.sort(u64, init_samples, {}, std.sort.asc(u64));
         std.mem.sort(u64, frame_samples, {}, std.sort.asc(u64));
@@ -212,7 +216,10 @@ fn measureStartup(io: std.Io, reps: usize, json: bool) !void {
             .reps = reps,
             .cold_ns = cold_ns,
             .init_median_ns = init_samples[reps / 2],
-            .init_p95_ns = init_samples[@min(reps - 1, reps * 95 / 100)],
+            // A p95 needs at least twenty samples to be one; below that this
+            // is the maximum and says so rather than dressing it up.
+            .init_p95_ns = if (reps >= 20) init_samples[reps * 95 / 100] else init_samples[reps - 1],
+            .init_max_ns = init_samples[reps - 1],
             .frame_median_ns = frame_samples[reps / 2],
             .allocations = calls / reps,
             .allocated_bytes = bytes / reps,