[david-fraley]

Fixes #40 (ENG-3479). Also fixes #38 and #41, so this supersedes #39, #42, and #43.

On cgroup v2, ContainerCPU and ContainerMemory stopped at the nearest cgroup with a limit and read usage from the process's own cgroup. The kernel enforces every limit from the process's cgroup up to the container root, so clistat could report 2% while an ancestor limit was about to kill the process, or 0 cores while nested containers were using 4.

How it works now

1. Walk from the process's cgroup up to the container root and collect every cgroup with a limit (cpu.max quota or memory.max).
2. For each one, read usage from that same cgroup. cpu.stat and memory.current include all descendants, so siblings that share the limit are counted.
3. Report the limit with the least room left (limit minus usage). Ties go to the cgroup nearest the process.
4. No limit anywhere: report the process's own usage with no total, as before.

If a limit owner has no usage files, the process's own usage is used for that limit (the same fallback #39 and #43 used). cgroup v1 and the public API are unchanged. The README has a new "How container limits are reported" section that documents this and says that limits above the container root, such as a Kubernetes pod limit behind a private cgroup namespace, are not visible.

Verification

• New NestedLimits tests: only an ancestor sets a limit (bug: cgroup v2 memory usage ignores sibling cgroups under the limit-owning ancestor (docker-in-docker, devcontainers) #38, bug: CPU usage misses other processes that share the same CPU limit (cgroup v2) #41), an ancestor limit runs out first (bug: clistat only checks the nearest limit, but every parent's limit applies (cgroup v2) #40), and the nearest limit runs out first. The first four fail on main. The nearest-limit cases pass on both and guard the old behavior.

• All existing tests pass unchanged. go test -race and golangci-lint are clean, except TestCgroupV2Detection/OsFs and TestIsContainerized/IsCorrectlyDetected, which also fail on main when run inside a container.

• Live, in a sysbox workspace (root cpu.max 1200000 100000, agent in /init.scope, 4 busy loops in a nested container):

  Build	ContainerCPU()
  main	0.004/12 cores (0%)
  this PR	4.01/12 cores (33%)

Decisions

• Report one limit, not all of them (the open question in bug: clistat only checks the nearest limit, but every parent's limit applies (cgroup v2) #40). The one that runs out first decides whether the process is throttled or killed, and that is what Coder's resource alerts and coder stat need. Returning every limit would change Result and push the choice onto every caller. A separate API can expose all limits later if someone needs them for debugging.
• One fix instead of three. fix: read cgroupv2 memory usage from the cgroup that owns memory.max #39 and fix: read cgroupv2 cpu usage from the cgroup that owns cpu.max #42/fix: read cgroupv2 cpu usage from the cgroup that owns cpu.max #43 are special cases of this rule (only one level has a limit), so this PR replaces them rather than stacking on them.
• CPU interface. cgroupStatter now returns cpuCounters(): one counter per limited cgroup, sampled together over the same interval, so CPU room is compared from the same window. cgroup v1 returns a single counter with its old values.
• Period. Each CPU counter uses the period from its own cpu.max. With no quota anywhere, the existing cpuPeriod() walk and the 100ms default still apply.
• Usage files on a limit owner are read without walking further up. Walking up would read a larger domain than the limit covers.

---

Generated by Coder Agents on behalf of @david-fraley.