Add ring deployment exec for interactive container access

[Shine-neko]

Adds ring deployment exec: run a command, or open a shell, inside a running instance.

ring deployment exec web-app                       # interactive shell
ring deployment exec web-app --no-tty -- ls /app   # one-off command

Opt-in via [server.exec] enabled = true; a server with it off answers 501. Docker only for now, other runtimes report that they do not support it. The command's exit code becomes the CLI's, so it composes with the shell.

Two things worth knowing when reading the diff:

Exec re-checks container ownership. Every other path in the Docker runtime reaches containers through list_instances*, which only ever yields containers carrying the ring_deployment label. Exec takes an id straight from its caller, so it has to re-establish that invariant itself, otherwise any id reaching the handler addresses every container on the daemon. Stream ticket scopes are separated for the same reason: a ticket minted for logs cannot be replayed to open a shell.

Sessions are bounded rather than killable. A container runtime gives no way to kill an exec once started, and dropping the connection leaves the process running. Ring cannot close that gap, so it bounds its own participation instead: a concurrency quota plus duration and idle timeouts, after which it stops relaying and frees the slot. The idle timeout is the one that matters in practice, since a client that vanished without closing stops producing traffic long before anything else notices.

The e2e caught a bug the Rust tests could not: with stdin already at EOF ($(ring deployment exec …)), the client closed the WebSocket, which tore the session down before the container had written anything. Every captured command came back empty with exit code 0. t44_exec.sh covers that case explicitly.

Two commits here are unrelated to exec but were needed to get CI green: h2 carries a DoS advisory published on 2026-08-17 (RUSTSEC-2026-0258, fixed in 0.4.16), and anyhow, event-listener and spin had unsoundness or yank warnings. All four are lockfile-only bumps within the existing semver ranges. They fail on main too; nothing in this branch pulls them in.