Support Apple's container runtime on macOS

[rhoopr]

Summary

Support running kei's published OCI image with Apple's container CLI on Apple silicon Macs.

The current ghcr.io/rhoopr/kei image already publishes a native linux/arm64 variant, and Apple container 1.1.0 provides the run, bind-mount, environment, exec, logs, port, and graceful-stop primitives kei needs. This should not require a separate image or direct Swift Containerization integration.

Current gaps

• Apple Containerization places the process in /container/<id>, but src/service/env.rs only recognizes Docker, containerd, Kubernetes, Podman, and LXC cgroup markers.
• kei status can therefore report not installed, while kei install and kei uninstall may try to manage systemd inside the container.
• kei doctor has a separate Docker-only probe, and personality only checks /.dockerenv.
• Container install/uninstall messages point specifically to Docker Compose.
• The install documentation only covers Docker commands and the NAS-oriented PUID/PGID path.

Apple's runtime also lacks several Docker Compose features kei currently relies on for unattended operation:

• no official Compose support: [Request]: Add container compose apple/container#1846
• no restart: unless-stopped equivalent: [Request]: Add support for --restart flag for run apple/container#286
• no container healthcheck observer: [Request]: Reserve HealthStatus enum + health field on ContainerSnapshot apple/container#1502
• no bind-mount UID/GID mapping: [Request]: Allow bind mounts with specific UID/GID apple/container#165

Scope

• Recognize Apple's /container/<id> cgroup path and report a useful supervisor name.
• Reuse the container detector across service status/install/uninstall, doctor, and terminal personality instead of maintaining Docker-only probes.
• Make install/uninstall guidance runtime-neutral.
• Document direct container run, exec, logs, stop, login, password, volume, metrics, and health-probe commands.
• Document the Apple silicon, macOS 26, and supported container version requirements.
• Document that the image should initially run as its default guest root user. Do not copy the NAS PUID/PGID recipe until Apple supports bind-mount UID/GID mapping.
• Add a focused smoke path for a real macOS 26 Apple silicon host.

Acceptance criteria

• container run --rm ghcr.io/rhoopr/kei:latest --version selects and runs the native arm64 image.
• /config and /photos bind mounts persist across runs, remain writable, and leave host ownership in a documented, safe state.
• The default image command starts kei service run successfully.
• container exec kei kei status reports container-managed operation rather than suggesting kei install.
• kei install and kei uninstall are safe no-ops inside Apple container with runtime-neutral guidance.
• container stop --time 30 kei produces a clean shutdown.
• /healthz, /metrics, login, 2FA, and encrypted password storage are exercised or documented with direct Apple container commands.
• Unit tests cover the Apple cgroup marker and avoid matching unrelated cgroup names.
• README/wiki installation docs state that Apple container currently has no official Compose, restart-policy, or healthcheck parity.
• Unattended macOS deployments continue to recommend the native binary plus kei install/launchd until Apple adds restart policies or kei deliberately ships a host-side supervisor.

Non-goals

• Implementing a Compose layer.
• Implementing restart or health supervision inside kei.
• Publishing a second container image.
• Integrating directly with Apple's Swift Containerization API.