Log why the 9p transport went away

[thomasjm]

When the transport dies, every in-flight request is failed with EIO and the reason is discarded:

// Transport error: stop pumping; the cleanup below fails all waiters.
Err(_) => break,

A clean end of stream isn't distinguished from an error, and neither is logged. So a caller sees an unexplained EIO and there is nothing on the client side saying the transport went away, let alone why.

That isn't hypothetical. In codedown CI this surfaces as an editor read failing with hGetBufSome: hardware fault (I/O error), reported to the user as "is it a valid Jupyter notebook?". Establishing that it was a transport death took ruling out the 9p server from its own logs — diod recorded no read errors at all, only later clunk: invalid fid complaints — and then reasoning backwards through transact's four EIO paths. The client knew the answer at the time and threw it away.

The change

Distinguish the two ways the pump can end, and log before clearing the waiters:

• Some(Err(e)) -> transport error: {e}
• None -> peer closed the stream

Then log at error with the reason, the number of in-flight requests, and what they were — T-message name, tag and age, the same information the stall watchdog already reports. If nothing was in flight it logs at warn instead, since no caller is about to see an EIO.

Logging happens before pending.clear(), so the in-flight list is still there to report.

No behaviour change: the same waiters are dropped and transport_gone is still signalled.

Note

This makes the failure diagnosable, it doesn't make it recover. Worth considering separately: a request outstanding when the transport dies could be retried on the reconnected session rather than failed, so callers don't have to treat EIO as normal. That's a bigger change — 9p fids are per-connection, so a retry has to re-walk rather than resend, and the clunk: invalid fid noise suggests stale fids already cross reconnects today.