#3629 [Engine] fix the host memory probe on hybrid cgroup hosts and on WSL2 without systemd

本文

## Problem and result

`host_available_memory()` returns false, so the engine treats the available RAM as unknown, on a hybrid cgroup host (Ubuntu 20.04-class distributions, WSL2 before 2.5 with systemd) and in a container on one. `0::/`, a host root group without `memory.max` (WSL2 without systemd), fails too.

With the RAM unknown, the resident RAM mode and `--resident-budget-gib` fall back to the file cache, a bare `--resident-cpu-experts` exits, and the #633 refusal of an arena larger than the container's limit is skipped without a message. This part is unconfirmed static analysis, from reading the callers.

With the fix these layouts read the visible v2 group, the v1 memory group or MemAvailable. A v2 group the mount shows in full, and a container with its own cgroup namespace, read as before.

## Related discussion

PR #1856 (AkaP88, closed in the 10-19 reset) fixed the `0::/` case alone; this covers it as the first new test. I found no issue or PR about the hybrid layouts.

## Approach

The probe returned false at the first `0::` line whose group is not a directory under the mount. Now:

- If the mount has no `cgroup.controllers` (a hybrid host's v1 tmpfs), the `0::` line adds nothing and the v1 memory group or MemAvailable decides, as the v1 branch already does for a group it cannot see.
- Otherwise the probe reads the deepest part of the `0::` path that the mount shows, as the memory guard's `group_dirs` (`conversation_memory.cpp`) does: `.` and `..` fail the probe, and a filesystem error counts as "not there".

The SYCL copy gets the same change. No new flag.

## Validation

Tested: fafa3c6f on main 011c9e60 (v0.2.2), WSL 2.3.26 with Ubuntu 24.04.1 (kernel 5.15.167.4, systemd), a hybrid layout.

**Passed:**

- `file_expert_source_test` (CUDA build, sm_120, nvcc 13.0.88; these cases need no GPU), eight new cases: on main it fails at the first (`v2 root group`); with the fix it passes; with the fix minus the `.`/`..` check it fails at the last (a path that leaves the mount).
- `host_available_memory()` copied verbatim from main and from this branch (`src/` and the SYCL copy) into a small program:
  - on this box (`5:memory:/init.scope`, `0::/init.scope`): main `false`; this branch `true`, 10.46 GiB (MemAvailable).
  - on the eight test layouts: six give `false` on main and a reading with the fix. The container with its own namespace (6 GiB, limit 8 GiB) and the path that leaves the mount (refused) are the same on both. The SYCL copy matches `src/` on every one.
- `strata` builds and links for CUDA (sm_120), HIP (gfx1201, ROCm clang 22) and SYCL (icpx 2026.1.1).

**Failed:** none observed.

**Not run:** the engine on a hybrid host or in a container on one: this box has no NVIDIA or AMD card, and my GPU machine is cgroup v2 only. Windows and macOS: the change is inside the Linux branch.

## Limits

- A v2 path the mount shows only in part is now read down to its deepest visible directory instead of failing the probe. If the mount does not start at the path's root, that directory may not be the process's own group: a limit below it can be missed, or a same-named sibling read, as with `group_dirs`. With no cgroup mount at all, MemAvailable decides.
- Other readers of the available RAM change on these hosts too: the file tier's read mode, the default CPU prefill share and an integrated GPU's cache size leave their "unknown" paths. None of this was measured end to end.
- On a hybrid host the v2 tree at `unified/` is not read; in systemd's hybrid layout it has no memory controller.