Runner: -cpus and -memory are accepted and never applied under rootless cgroupfs #188

Found while validating the memory cap for #184 on bay1 (2026-09-07).

The container's OCI spec carries the requested limits with an empty cgroup path:

cgroupsPath: None
resources: {"memory": {"limit": 6442450944, ...}, "cpu": {"quota": 300000, "period": 100000}}

and podman inspect reports State.CgroupPath=/system.slice/gitbay-runner.service: the container's processes live in the runner service's own cgroup, whose memory.max and cpu.max are max. No child cgroup exists. The service cgroup has an empty cgroup.subtree_control, and it cannot be enabled because the runner process itself is in that cgroup (the no-internal- process rule). So under --cgroup-manager=cgroupfs as a system service, -cpus and -memory (89eba6a) have never applied. The runner logs nothing about it.

Options:

1. The runner moves itself into a leaf child cgroup at start, enables +cpu +memory +pids on its original cgroup's subtree_control, and passes --cgroup-parent so crun creates a child per container. No DBus, works as a system service.
2. The systemd cgroup manager, with XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS for the lingering user manager in the step environment. This is what 74b01ee moved away from.
3. Refuse to start when -cpus/-memory are set and the container's cgroup turns out to be the runner's own, so the operator learns it at deploy rather than at an outage.

Until one lands, the cap is on the unit: MemoryMax, CPUQuota and OOMPolicy=continue in the drop-in (#184).