initCgroupParent skips the parent-process move at group "/", assuming the real root cgroup, which is exempt from the no-internal-process constraint. in a private cgroup namespace (podman and docker's default on cgroup v2) "/" is a populated delegated NON-root cgroup instead, so the first workflow fails: 'failed to write subtree controllers [memory pids] to "/sys/fs/cgroup/cgroup.subtree_control"': EBUSY. userspace cannot tell the two "/"s apart — cgroup namespaces virtualize /proc/self/cgroup and mountinfo for the reader — but the constraint can: it exempts only the real root. probe it by writing +memory +pids to cgroup.subtree_control: succeeds at the real root (the same write prepareCgroup does per microVM anyway), EBUSY at a populated namespace root, where we then vacate exactly as on the group != "/" path. a read-only cgroupfs now fails loudly at init instead of mid-workflow. verified in scratch podman containers: unpatched reproduces the EBUSY, patched passes the new regression test and enforces memory.max. Signed-off-by: Winter <winter@madoka.systems>