fix(cli): size the TUI V8 heap from this process's cgroup, not the hierarchy root (SCA-4627)

[pai-scaffolde]

Stacked on #64 (which is stacked on #63). Review only the two commits above #64's tip; the base will collapse to main as the stack merges.

The defect

Codex flagged this as P1 during review of #64. hermes_cli/main.py _read_cgroup_memory_limit() read the identical two hierarchy roots that SCA-4623 just fixed in agent/lsp/manager.py:

candidates = (
    "/sys/fs/cgroup/memory.max",                    # cgroup v2
    "/sys/fs/cgroup/memory/memory.limit_in_bytes",  # cgroup v1
)

Those are this process's limit only when it sits in the root cgroup. Under a systemd unit with MemoryMax=, or in a container without a private cgroup namespace, the root reads max and the function returns None.

Why it is worse than the LSP cap

_resolve_tui_heap_mb() then returns the flat default_mb = 8192. V8 is not cgroup-aware, so inside a 4 GiB unit the Node TUI grows its heap toward 8 GB until the cgroup OOM killer SIGKILLs it. Per that function's own docstring, the kill runs no JS handler, writes no [tui-parent] breadcrumb, and the user sees only a bare gateway stdin EOF.

SCA-4623's defect degraded to pre-cap sizing. This one is a silent kill with no diagnostic.

The change

Two commits, deliberately split:

1. refactor(cgroup) — pure move of the resolver out of agent/lsp/manager.py into a new stdlib-only agent/cgroup_memory.py, matching the flat single-purpose convention of agent/battery.py. manager.py keeps host_memory_bytes() and delegates. No behaviour change.
2. fix(cli) — _read_cgroup_memory_limit() becomes a delegation to that module.

hermes_cli deliberately does not import agent.lsp.manager: LSP is unrelated to heap sizing and that module pulls asyncio plus the whole LSP client stack onto a CLI startup path. The new module imports in 9 ms with no asyncio, logging, or threading behind it (measured, not asserted).

cgroup_memory_limit_bytes (no underscore) is the single name crossing a module boundary; the resolution helpers stay private.

Positive control

Required, as in #64. Four new tests over a fabricated /proc + cgroupfs tree — hierarchy root at max, the real limit on the unit's own cgroup — each shown failing against the fixed-path implementation before the fix:

Test	Failure before
test_unit_limit_is_read_not_the_hierarchy_root	assert None == 4 GiB
test_heap_is_sized_below_the_unit_limit_not_the_flat_default	assert 8192 == 3072
test_an_ancestor_limit_binds_the_unit	assert None == 2 GiB
test_absent_proc_still_falls_back_to_the_fixed_paths	assert None == 6 GiB

assert 8192 == 3072 is the defect itself: the heap V8 would have been handed inside a unit that cannot afford it.

Test trap closed

tests/hermes_cli/test_tui_heap_sizing.py mocked builtins.open and passed unrecognised paths through to the real open. Once resolution consults /proc, those fixed-path tests would have read the real /proc on Linux CI and started reporting the runner's own cgroup. _read now pins CGROUP_FS_ROOT at an empty root first — the same guard no_proc() gives the LSP suite in tests/agent/lsp/test_client_cap.py.

The cgroup tests in test_client_cap.py move their patch targets to the new module alongside the code. Same tests, same assertions, no coverage lost.

Class sweep

git grep -n "sys/fs/cgroup" -- '*.py' '*.ts' '*.js' '*.sh' — 3 readers; 2 fixed, 1 tombstoned:

Site	Status
agent/lsp/manager.py	fixed in #64, now delegates
hermes_cli/main.py	this PR
gateway/cgroup_cleanup.py	not a sibling — builds /sys/fs/cgroup{cgroup_path}/cgroup.procs from a caller-supplied path rather than assuming the root. Tombstoned.

Verification

• tests/hermes_cli/test_tui_heap_sizing.py — 9 passed
• tests/agent/lsp/ — 104 passed (extraction is behaviour-preserving)
• tests/tools/test_docker_environment.py + tests/hermes_cli/test_agent_import.py — 99 passed
• ruff check clean; ty check clean on both changed source modules

Closes SCA-4627.