investigate where guest input processing stalls

Context

Follow-up to #1335 and the Greptile review comment.

The PR deliberately treats 60 seconds of blocked guest input as a recoverable stall: reject new connections, retain bounded pending input, preserve existing clients and output, and reopen admission when input drains. Input blockage alone does not establish that the VM is dead, so this timeout does not terminate it. A permanent stall can nevertheless retain VM resources until explicitly stopped.

We need to identify exactly where forward progress stops and why, rather than infer the cause from a full input queue.

Investigation

• Trace control and bulk input from client admission through relay queues, console transport, guest reads, and agent dispatch. Identify blocking waits, lock contention, and downstream backpressure at each boundary.
• Reproduce sustained stalls and distinguish a slow or busy guest from a lost capacity wakeup, transport failure, or deadlock. Record the last stage that made progress.
• Add focused diagnostics where needed: lane, queue occupancy, blocked duration, capacity notifications, and guest consumption progress. Avoid recording request payloads or secrets.
• Check whether control traffic can still progress when bulk traffic is blocked, and whether output and explicit shutdown remain responsive.
• Use the findings to recommend a targeted fix and determine whether any separate, configurable cleanup policy is warranted. Do not introduce automatic VM termination solely because the input queue has been full for 60 seconds.

Completion criteria

• A reproducible stall with evidence locating the blocked stage, or a documented account of scenarios tested and remaining gaps.
• Regression coverage for any confirmed defect and verification that transient backpressure recovers without losing existing work.
• A clear distinction between recoverable input blockage and conditions that justify VM cleanup.