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.

0 files changed, 0 insertions, 0 deletions