Give up on a stalled 9p request instead of hanging the mount forever

[thomasjm]

A 9p server that stops answering — a silently dead tunnel, or a server wedged on its backing store —
hangs every process that touches the mount, with no timeout anywhere. The kernel v9fs client waits
forever by design, and the FUSE bridge's session loop is serial, so one unanswered reply wedges the
whole mount and nothing recovers it.

Adds --stall-timeout (default 30s, 0 disables) to both subcommands:

• mount9p-fuse: the client's pending map now carries the T-message type and a timestamp. A request
  unanswered past the deadline declares the transport dead, which fails all waiters and flips the
  existing transport_gone watch — so the daemon takes the path it already had for a closed
  transport: detach the mount and exit for the supervisor to remount.
• mount9p: the byte pumps scan frame headers to track outstanding tags (including Tflush
  abandoning its oldtag), and the same deadline exits the daemon, which MNT_DETACHes so the
  kernel fails blocked waiters with EIO.

The frame scanner reads only the 9-byte header per frame and skips bodies, so it adds no buffering
to the byte path. It handles arbitrary chunk boundaries; there's a unit test feeding the same stream
at every chunk size from 1 upward, plus one pinning that a short frame doesn't report a stale
oldtag from the previous frame.

Verified against a real diod over TCP, mounted via mount9p-fuse, with the server SIGSTOPped
and a lookup forced to miss the attr/entry cache:

• --stall-timeout 30: 9p request stalled; declaring the transport dead tag=19 mtype="Twalk" age_secs=33, then detaching the mount and exiting so it is remounted. The blocked process was
  released and the daemon exited.
• --stall-timeout 0 (control): still blocked past 75s.

Note a process already blocked in chdir stays in uninterruptible sleep until the mount actually
goes away, so the recovery bound is the timeout, not immediate.

cargo test passes, including the 15 diod integration tests.