Cells on the forge pod have no kernel memory or process cap #10518

Class: resource isolation between a child forge (or any cell) and the parent forge.

On the vxrail forge pod no delegated cgroup is found (apps/cgroup.ts cgroupHost: not at a cgroup namespace root), so every cell, including a child forge's, runs in the pod's own cgroup. Memory is enforced only by the 1 s watch (watchTree), and nothing caps the number of processes. Code inside a cell can then use the pod's memory or process table faster than the watch reacts, and the whole forge goes with it.

This needs an owner decision on the deployment: delegate a cgroup subtree to the forge container (cgroupns plus a writable /sys/fs/cgroup subtree, or FORGE_CELL_CGROUP), so cells get memory.max and pids.max from the kernel. Test: on the pod, memoryCapHolder() answers kernel.

Found in the child-forge isolation audit, 2026-11-10.

The owner gave the go (11-10: "I want to make sure we have the proper defenses"). Delegate a cgroup to the forge pod for cells. This is part 2 of #10850, which also covers disk, CPU/io, rlimits and the hostname. Do it through the release path, with zero downtime.