[Bug]: container exec/stop hang indefinitely on SSH reconnect, requiring full macOS restart to recover

### I have done the following

- [x] I have searched the existing issues
- [ ] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

1. Start a container with a bind mount: container run -d --name test0 -v :/code ubuntu:latest
2. Install openssh-server inside it and configure key-based SSH access.
3. Connect via SSH (e.g. VS Code Remote-SSH, or plain `ssh`). This first connection works fine.
4. Disconnect (e.g. restart VS Code, or point Remote-SSH at a different folder within the same container).
5. Attempt to reconnect via SSH, or run `container exec -it test0 bash` directly.
6. The exec/SSH session hangs indefinitely — no prompt, no error, no timeout.
7. `container stop test0` also hangs with no output.
8. `container list --all` continues to report the container as "running" throughout.

In a second occurrence the same session, `container system stop` also hung (log showed `stopTimeoutSeconds=5 ... stopping containers` then nothing further — the stated timeout was not enforced), and `launchctl kickstart -k ` did not recover it either. A full macOS restart was the only thing that restored a working state.

Separately, `ps aux` showed multiple stuck `container exec` client processes accumulated from repeated attempts (none had exited on their own), while `container-runtime-linux` and `container-apiserver` processes appeared healthy — suggesting the hang is in the exec/PTY session layer, not the VM or daemon itself. `ping` to the affected container's IP succeeded instantly while `exec` was hung, ruling out a network-layer cause.

### Problem description

container exec (and subsequently container stop / container system stop) can hang indefinitely, specifically triggered by reconnecting to a container via SSH/exec — the first connection after starting/configuring the container works fine, but a second or later connection attempt reliably triggers the hang. This suggests something isn't being cleaned up when an exec/SSH session ends, and the leftover state blocks the next session.

Separately, `container list --all` reported a container as "running" while `container exec` on that same container immediately failed with `cannot exec: container is not running` — a state-tracking inconsistency between the two commands.

Expected behavior: exec/SSH sessions should be able to reconnect repeatedly without hanging, and container stop should always respect its stated timeout rather than hanging indefinitely and requiring a full OS restart to recover.

### Environment

```markdown
* OS: macOS 26.5.2 (Tahoe)
* Hardware: Apple Silicon (M4)
* Container: Container CLI version 1.1.0 (installed via Homebrew)
* Image: docker.io/library/ubuntu:latest (Ubuntu 26.04 LTS, arm64)
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start by reproducing the SSH reconnect sequence with `container exec`, then inspect the `container exec`, `container stop`, and `container system stop` logs and stuck processes described in the report. Done means repeated SSH or exec reconnects work, `container stop` respects its timeout, and `container list --all` reports consistent container state without requiring a macOS restart.

Written by the indexing model from the issue text.