detached: a daemon serves acme's control filesystem, in its own poll and with no thread

Step 1 of the 9P chain (docs/9p.typ 12.1, docs/registry.typ 9P-14).

A detached session was the one configuration no script could drive. The core,
the panes and the undo history outlive every frontend that attaches -- and the
filesystem that would let a program read or change any of it was never mounted,
because `push_fs_reply` was one of the host methods this process left null.
Nothing prevented it; the call was simply not there.

It costs less here than in the desktop shells. They start a thread that blocks
on poll() and pokes a loop it does not otherwise share (`fs_service.wake`);
this process already runs ONE poll over its listener, its frontends, its pane
shells and inotify, so /dev/fuse is one more descriptor in the same syscall and
there is no thread at all. `Source.fuse`'s arm does nothing on purpose: being
in the set is the whole point, because the wake must end the sleep so that
`pollFrame` -- which runs after `pull_wait_input` returns, where re-entering
the core is legal -- reaches the drain.

`main.zig` refused `--detach --fs` outright, with a comment saying that
serving it would mean mounting FUSE in the detached core and that this was a
feature rather than a fix. It was right, and this is the feature. `--attach`
is still refused: a frontend has no core to serve.

Verified against the project's own clients: examples/acmefs/pardesctl panes,
new, send, body and del all drive a daemon, and the pane shells it forks now
inherit PARDES_FS/PARDES_PANE like every other host's.

0 files changed, 0 insertions, 0 deletions