feat(macos): run containers inside a bottle via guest-local podman

Adds the `nested_containers` bottle flag. On the macOS backend it starts
a rootless podman service inside the bottle and exposes its
Docker-compatible API socket, so the agent still runs `docker` and
`docker compose`. No host daemon socket is mounted and the guest gains
no capabilities; backends that cannot run a guest-local engine reject
the flag in the shared prepare template rather than ignoring it.

Podman rather than rootless Docker because Apple Container's capability
bounding set omits CAP_SYS_ADMIN, which the kernel requires to write a
multi-range uid_map via newuidmap. With no subordinate UID range podman
falls back to a single-UID self-mapping an unprivileged process may
write itself, so the image build strips /etc/subuid and /etc/subgid
entries rather than adding them.

That mapping is also why nested containers are not an isolation layer:
root inside one is the agent user outside it. They are a build/test
convenience; the bottle remains the boundary.

Ports the spike branch onto main, renaming docker_access — it implied
Docker and granted access to nothing on the host — and drops podman
from the derived layer now that every built-in image ships it (#451).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

README.md

@@ -75,6 +75,49 @@ On compatible macOS hosts, the default backend requires Apple's `container` CLI
 
 Use `BOT_BOTTLE_BACKEND=docker ./cli.py start <agent>` on hosts where neither Apple Container nor KVM is available and Docker is the desired backend.
 
+### Containers inside a bottle
+
+A bottle may set `nested_containers: true`. On the macOS backend this starts a
+guest-local, rootless **podman** service after the bottle is registered and
+exposes its Docker-compatible API socket, so the agent still runs `docker` and
+`docker compose`. Nothing is mounted from the host: Docker Desktop's socket
+stays out of the bottle and the guest gains no outer VM capabilities. Backends
+that cannot do this (`docker`, `firecracker`) reject the flag rather than
+silently ignore it.
+
+Rootless Docker was tried first and does not work here at all: Apple
+Container's capability bounding set omits `CAP_SYS_ADMIN`, which the kernel
+requires to write a multi-range `uid_map`. See
+[`docs/research/rootless-docker-in-apple-container-spike.md`](docs/research/rootless-docker-in-apple-container-spike.md).
+
+The tradeoff to understand before enabling it: podman avoids that requirement
+by falling back to a single-UID mapping, so nested containers provide **no
+isolation from the agent itself** — `root` inside a nested container is the
+agent user outside it. Nested containers are a build/test convenience, not a
+security boundary. The bottle remains the boundary.
+
+Pulling images goes through the bottle's egress proxy like every other
+request, so each registry needs a route. Docker Hub and GHCR additionally need
+`preserve_auth: true` (their token dance uses a client-fetched per-scope bearer
+token that the proxy would otherwise strip), and large layer pulls should skip
+body scanning:
+
+```yaml
+nested_containers: true
+egress:
+  routes:
+    - host: registry-1.docker.io
+      preserve_auth: true
+      dlp: { outbound_detectors: false, inbound_detectors: false }
+    - host: auth.docker.io
+      preserve_auth: true
+    - host: ghcr.io
+      preserve_auth: true
+      dlp: { outbound_detectors: false, inbound_detectors: false }
+    - host: quay.io
+      dlp: { outbound_detectors: false, inbound_detectors: false }
+```
+
 ### Firecracker on Linux
 
 On Linux, a KVM-capable host defaults to the Firecracker backend. It needs: