9p: serve the acme tree over 9P2000 on a unix socket, beside the mount

Step 4 of the 9P chain (docs/9p.typ 12.4, docs/registry.typ 9P-15/16/17/4/5).

src/9p.zig is a base 9P2000 codec and a SANS-IO server: it never touches a
descriptor, takes no allocator, starts no thread, and builds for
wasm32-freestanding and riscv32-freestanding. That is what lets the same code
serve a unix socket here and a UART on the board later.

  Server(comptime fs: type)   duck-typed on fs.Req/fs.Reply/fs.Reply.Attr, so it
                              never imports acmefs and acmefs never learns 9P
  init{ in, out, root }       the caller owns the buffers; msize is derived
  retry/next/reply            the three fs_service.Transport ops, by name
  push/output/wrote/hangup    bytes in, bytes out, partial writes supported

next() is a PUMP, not one-message-one-request: a 3-element Twalk is three
lookups, Topen|OTRUNC is a setattr then an open, Tversion is none at all.

Decisions that were open and are now taken, each recorded in the file:
  * qid.version is ALWAYS 0, which makes Linux set P9L_DIRECT and skip its
    cache -- the 9P equivalent of the FOPEN_DIRECT_IO fuse.zig relies on.
  * Every Rread is clamped to the client's count. An over-long one is a hard
    -EIO in Linux, not a truncation.
  * Rerror carries Linux's exact strerror text (registry 9P-4 option A), so a
    mount recovers the errno instead of ESERVERFAULT. Asserted as literals,
    because a typo there is 'Unknown error 526' on every mount.
  * `.` and `..` are resolved BY THE SERVER. Under FUSE the kernel does it
    and acmefs says so; 9P has no kernel, and forwarding `..` as a lookup
    would break every client that normalises a path.
  * Topen checks the perm bits itself. Under FUSE the kernel enforced them;
    over 9P nobody is above the server, and `errors` would have been readable.
  * Tcreate and Tremove are Rerror: `new/` creates a pane on WALK, so the
    capability exists and is not spelled Tcreate.

THE INTEGRATION BUG, which was not in the protocol: the daemon's push_fs_reply
sent every reply to the FUSE mount, whose park table has no 9P tag, so it
dropped it -- Tversion worked (no core involved) and Tattach hung forever. That
is exactly the 'no routing origin for the 9P descriptor' cell in the layering
table of docs/9p.typ. Session.fs_origin now carries the transport that asked.

Proved with plan9port against a live daemon serving BOTH transports at once:
9p ls / and /1, read index/ctl/tag, write /1/body, stat, a walk through
/1/../index, pane creation through `new/body`, and the two refusals arriving as
strings -- 'permission denied' and 'No such file or directory' -- confirmed on
the raw wire as Rerror text rather than numbers. A write over 9P reads back
through FUSE and a write through FUSE reads back over 9P.

msize 8192, 34,072 bytes per connection (Server 9,488 + in 8,192 + out 16,384,
out being two msize so that every reply is infallible), four connections.
zig build unit-test: 468 tests before, 503 after.

1 files changed, 17 insertions, 0 deletions

diff --git a/src/pardes.zig b/src/pardes.zig
index 111e2853..4fdb6c71 100644
--- a/src/pardes.zig
+++ b/src/pardes.zig
@@ -5638,6 +5638,23 @@ pub const Options = struct {
     /// browser) has no filesystem at all — but the option rides here because
     /// argv already reaches the shells this way, like `nested`.
     fs: ?[]const u8 = null,
+    /// SERVE THAT SAME TREE OVER 9P2000 on a unix socket (`--fs9`), and under
+    /// what name. `null` is off; `""` means "derive the socket name" (the
+    /// session name in a daemon, this pid anywhere else); anything else is the
+    /// name `--fs9=<name>` gave, which scripts need because they have to
+    /// predict `$XDG_RUNTIME_DIR/pardes-9p-<name>.sock`.
+    ///
+    /// INDEPENDENT of `fs` above: either, both or neither. They are two
+    /// transports onto one tree (`src/acmefs.zig`) and neither is the other's
+    /// prerequisite — on Linux the FUSE mount needs `fusermount3` and a
+    /// kernel with FUSE, and this needs neither, which is the whole reason
+    /// docs/9p.typ §12.4 calls them complementary rather than competing.
+    ///
+    /// Read by `detached/server.zig` and nowhere else so far: a daemon polls
+    /// its own listener in the one `poll(2)` it already runs, which costs it
+    /// no thread. The tty and GUI shells would each need their own wake for
+    /// it, exactly as they need one for `/dev/fuse`, and they take `fs` only.
+    fs9: ?[]const u8 = null,
     /// Native launcher's resolved per-user `pardes` directory. Relative
     /// ThemeFile operands and DumpThemes are rooted here. Null for web and
     /// direct core callers which did not opt into per-user configuration.