fix: prevent panic from crashing the whole server

[taciturnaxolotl]

Panics raised while serving an SSH connection no longer terminate the server process. They are contained to the connection that caused them, logged with a stack trace, and the session ends with a non-zero exit status.

The big bad bug

Every connection is served on its own goroutine, and the handshake and session handlers run there. Go has no process-wide panic handler, so a panic on any of those goroutines killed the entire process and disconnected every other user.

The panic does not have to come from application code. A fault while decrypting or parsing an incoming packet happens before authentication, so an unauthenticated client could take a server down.

• roughly 700 repositories depend on this library
• effectively none of them use wish's recover middleware, including our own examples

So nearly every SSH server built on this library is currently susceptible to a panic crashing their program.

The fix

Recovery has to be installed on the goroutine that panics, because a recover only sees panics unwinding its own stack. That rules out the accept loop, connection callbacks, and session middleware: by the time any of those return, their deferred functions have already run. So every goroutine started per connection gets its own handler.

Compatibility

No exported API changes. All new symbols are unexported and HandleConn's signature is untouched, so callers who invoke it directly just get containment for free.

Behaviour changes worth noting:

Change	Effect
Panics no longer crash the process	The point of the change
Panics logged via slog at error level	New log volume on a previously silent path
Session panics send exit-status 1	Clients see a clean non-zero exit instead of a dropped connection

Connection close callbacks still fire and shutdown accounting is still released on the panic path, so a graceful shutdown does not hang waiting on a connection that already died. There is a test pinning that.

Found while assessing exploitability for GHSA-v57m-p5gf-9mf5 in soft-serve, where the missing recovery is what turns a handshake panic in x/crypto/ssh into a full outage. This is not itself an advisory — it isn't independently exploitable, since it needs a separate panic bug to weaponise. It's an impact multiplier, and the pattern is inherited from gliderlabs/ssh upstream, which has the same gap.