feat: bake podman/uidmap/fuse-overlayfs into the actions-runner image

[elasticdotventures]

Summary

Adds podman (+ uidmap, fuse-overlayfs) to the runner image, and a new publish-podman-runner.yml workflow that builds/pushes to this fork's own GHCR namespace (ghcr.io/promptexecution/actions-runner-podman), independent of upstream's release-branch-driven docker-publish.yml.

Built for app4dog/middleware#92 (CI's build-image job fails on a self-hosted runner with no docker.sock — docker was deliberately purged in favor of podman-only).

Important finding

Verified locally: the image builds clean, podman --version/podman info work when run directly. But podman run as the runner user inside a container started from this image still can't create its own nested rootless user namespace — newuidmap: write to uid_map failed: Operation not permitted, reproduces even with --privileged on the outer container. This is a real, empirically-confirmed kernel limitation (nesting rootless user-namespace creation two levels deep), not a missing capability flag.

So this image alone doesn't make podman usable for actual builds on a runner that's itself deployed as a rootless podman pod — the consumption model needs to be host-podman-socket passthrough (CONTAINER_HOST pointing at a mounted host podman.sock) rather than this image's own podman trying to create a third nested namespace layer. That wiring lives in the b00t-cli gh-runner tooling, not this repo.

Test plan

• podman build -f images/Dockerfile --build-arg RUNNER_VERSION=2.336.0 — clean build
• podman run --user runner <image> podman --version — works
• /etc/subuid//etc/subgid correctly allocated for the runner user
• Confirmed the nested-namespace limitation empirically (not guessed) — same failure with default caps, explicit --cap-add SETUID --cap-add SETGID, and --privileged
• Not yet validated against the actual fung1 self-hosted runner topology — pending