Bound what an unauthenticated SSH client can spend

Bound what an unauthenticated SSH client can spend

The SSH listener accepted every connection, gave each one a goroutine, and
started a process per session channel. A client that opened a socket and
never finished the handshake held all three for as long as it liked, and a
client that opened channels held a goroutine each. The host key was
hardened by `vole serve` on the way in, but the SSH package on its own
would happily load a key the whole machine could read.

Four bounds, all enforced before the expensive thing happens:

  - A handshake deadline, cleared once the handshake completes so a clone
    or a push is not cut. `ssh_handshake_timeout_seconds`, default 20.
  - `ssh_max_connections` (default 64) tokens, one per open connection. Past
    the cap the connection is closed before the handshake, the goroutine or
    the process, and the accept loop keeps running so the listener cannot be
    wedged. The "listener is full" warning is throttled to once per 10s so a
    flood cannot become a disk problem instead.
  - Eight session channels per connection, rejected at the channel layer
    rather than by spawning a goroutine per request.
  - `ssh_max_git_processes` (default 16) across every connection, covering
    upload-pack, receive-pack and vole-change-merge. A command waits up to
    30s for a slot and is then told to retry, rather than parked forever.

Payloads are bounded too: an exec line over 4 KiB is refused before it is
parsed, and a vole-runner request line over 1 MiB ends the session with an
error. The runner bound is a per-line reader, so json.Decoder's buffering
cannot hide an oversized request and a long-lived runner is not limited in
total.

Loading an existing host key now tightens it to 0600 and warns, and a mode
that cannot be tightened fails startup, so the package is safe on its own
rather than only behind `vole serve`.

Tests hold a connection without handshaking (it is dropped and its slot
returns), flood one connection with channels (the ninth is rejected and
closing one releases a slot), send an oversized exec line and an oversized
runner request (both refused), saturate the process pool (a bounded wait,
then a refusal), and load a 0644 host key (tightened).