Report an unreachable sbx SSH endpoint in diagnose

[czpython]

The gateway tunnel runs sbx ssh proxy. In a container without the sbx cache, the CLI reads no feature flags and sees the daemon's SSH endpoint as off. Then the tunnel fails, but diagnose still passed, because it ran only sbx ls.

Changes:

• diagnose also runs sbx ssh proxy through the new SbxCLI.check_ssh_endpoint, and it requires the daemon's SSH- banner. The probe uses a sandbox name that does not exist. The daemon sends its banner before it selects a sandbox, so the probe creates and wakes no sandbox. A CLI that sees the endpoint as off exits with an error, and /doctor reports it.
• The container recipe in docs/deploy.md:
  • mounts the directory of the daemon socket, not the socket file, so a daemon restart does not cut the container off;
  • sets XDG_CACHE_HOME and XDG_STATE_HOME, and mounts the sbx cache;
  • runs the container with the uid of the daemon owner, and says that the gateway container needs the same mounts.
• The recipe mounted the auth store read-only. The Druks compose notes that a read-only auth store fails each create, and that the CLI needs a writable settings store. The recipe now mounts both writable, and XDG_CONFIG_HOME points to them.

Validation:

• uv run pytest: 743 passed on SQLite. Ruff, format checks, and Pyright passed.
• New tests cover the banner, the "endpoint is disabled" error, output without a banner, and diagnose with an unreachable endpoint.
• On macOS with sbx v0.45.1, check_ssh_endpoint passed against the real daemon, and sbx ls showed no new sandbox.

Not tested: the Linux container recipe. On macOS, sbx keeps its cache in ~/Library/Caches and ignores XDG_CACHE_HOME, so the Linux paths come from the issue. The Druks compose change will test them on the deploy host.

Refs #61. The compose change for the Druks deployment is still open.