`server container install`: runtime-neutral containerized install (Docker + Podman)

Docker's a drag to install, so this started as "support Podman too" — but the clean way there was to stop hard-coding Docker in the containerized install path at all.

So the real change is a container-runtime abstraction: miren server docker install becomes miren server container install (the old server docker * commands stay as deprecated aliases), driven by whichever runtime you've got. The runtime engine itself was never Docker-based — it's containerd + buildkit under the hood — so this only touches the install path and the debug bundle.

What ships:

• server container install / status / uninstall, with server docker * kept as deprecated aliases
• --runtime docker|podman (auto-detects, prefers Docker when both are present), plus a MIREN_CONTAINER_RUNTIME env override
• debug bundle collects from whichever runtime is hosting the container

Supported runtimes: Docker (rootful by default) and rootful Podman. Verified end-to-end on macOS podman 6.0 rootful: install, control plane, real app deploys including a Postgres app on a persistent LSVD disk, teardown, and the debug bundle.

Out of scope (follow-up): rootless Podman — the server and control plane come up, but app sandboxes can't start (we do privileged nested containerization that assumes a rootful runtime). Tracked in MIR-1313. Related: LSVD provider = "miren" disks need loop devices (CAP_SYS_ADMIN), so they're rootful-only regardless; provider = "local" is the portable option.

Original ask: "I'm dreading docker but for miren I just installed it again just now. How about supporting podman as well?"