feat(session): surface exec exit-status / exit-signal via SshSession.exitInfo

[GlassOnTin]

What

Adds SshSession.exitInfo: Deferred<SessionExit?> — the RFC 4254 §6.10 exit-status / exit-signal reports, which the packet loop previously parsed (the kaitai types were already wired into SshMsgChannelRequest) but dropped after logging. Without this, an exec consumer can read stdout/stderr to EOF but never learn how the command terminated.

• SessionExit sealed interface: Status(code) / Signal(signalName, coreDumped, errorMessage)
• Completed from the connection's channel-request dispatch for session channels; first report wins per the RFC
• Resolves to null when the channel closes without a report (servers aren't required to send one), so waiters are never left suspended
• Metalava signature updated; metalavaCheckCompatibility passes

Why

Haven is adopting sshlib as its second SSH engine (context in GlassHaven/Haven#58); the next slice is remote command execution, where automations branch on exit codes. This was the one missing piece for exec parity — happy to adjust the API shape (e.g. a suspend accessor instead of the exposed Deferred) if you'd prefer.

Tests

• 4 FakeSshServer flow tests: exit-status completes exitInfo; exit-signal completes it; close-without-report resolves null; first report wins over a later one
• 2 Testcontainers integration tests against OpenSSH 9.9p2: sh -c 'exit 42' → Status(42); a KILL-terminated command → Signal("KILL", …)
• Full :sshlib:test suite: 1170 tests, 0 failures (unit + integration, Docker available)

[GlassOnTin]

Some context on where this fits, @kruton, for whenever you next have review bandwidth (CI is green across JDK 17/21/25 + CodeQL).

This closes the last gap for adopting sshlib as a second SSH engine in Haven — the migration you kindly kicked off back in GlassHaven/Haven#58 when you reached out about ssh-proto. Since then the exec (#95), subsystem (#98), SFTP (#112) and FIDO2/SK (#146) work all landed upstream, and Haven now has the per-engine building blocks built and tested against real servers:

• SFTP — shipped and device-verified on Haven's daily driver.
• Shell / PTY — done, contract-tested against JSch byte-for-byte (banner-first-bytes, echo, resize, clean-exit).
• Port forwarding (local / remote / dynamic SOCKS5) — done, contract-tested.

The one thing still missing is a truthful command exit status. Haven runs execCommand to detect tmux/zellij/screen sessions and to bootstrap Mosh/Eternal-Terminal, and those flows branch on the exit code — so the library dropping the RFC 4254 §6.10 exit-status/exit-signal report (the kaitai types already parse it; the packet loop just discards it after a debug log) means the exit code can't be surfaced honestly. Rather than fabricate a value, Haven has that whole path gated behind this PR: once it lands in a release, a sshlib-toggled Haven profile can run its terminal, tunnels and file transfer entirely over sshlib instead of JSch.

Happy to reshape the API if you'd prefer something other than an exposed Deferred<SessionExit?> — e.g. a suspend fun awaitExit(): SessionExit? accessor, or folding it into the existing close/lifecycle signalling. Whatever fits the library best; the wire parsing and tests are the substance.