[raggi]

An authenticated client could exhaust memory in the server process with per-session state that persisted after disconnect, in two ways:

1. A window-change request did a blocking send on the session's window channel. The channel has capacity for one window size and the initial pty-req already fills it, so if the session handler never drains the channel returned by Pty(), the very first window-change parks the handleRequests goroutine forever. The parked goroutine, the session, and everything it references (such as accumulated environment variables) leak even after the client disconnects, and the request loop stops servicing any further requests for the session.

2. Before a shell or exec request was handled, every env request appended an arbitrarily sized "key=value" string to the session's environment with no cap on count or size, so an env churn loop grew the heap without bound.

Window-change sends are now non-blocking and keep-latest: when the consumer is not keeping up, the stale buffered value is replaced with the newest window size, so a slow consumer eventually observes the most recent size and the request loop never blocks. Break requests had the same blocking send on the registered break channel and are now dropped (replied false) when the consumer is not keeping up. Env requests are rejected once a session has maxEnvs (128) variables.

While here, fix a data race between handleRequests writing the pty window size and the handler goroutine reading it via Pty(): both now take the session mutex, which previously went unused for pty state.

Thanks to the security audit that identified the memory exhaustion condition (approximately 536 MB allocated in 7 seconds of churn, persisting long after disconnect when a parked goroutine retained the session).

Updates tailscale/corp#50380