feat(platform): cgroup-aware CPU/memory detection in detect_system_linux

[yangsec888]

Summary

Closes #363 in conjunction with #364: this PR is the auto-detect half of cgroup-awareness; #364 is the CBM_WORKERS env-override escape hatch. They're independent and can land in either order.

Today detect_system_linux() reports host CPU count via sysconf(_SC_NPROCESSORS_ONLN) and host RAM via sysinfo(). Inside a container, neither reflects the cgroup's effective quota, so cbm_default_worker_count over-provisions workers and the SQLite mmap budget can exceed the cgroup memory cap — see #363 for the OOMKill story.

This PR makes the Linux detection path cgroup-aware:

1. CPUs: read <root>/cpu.max (v2) or <root>/cpu/cpu.cfs_quota_us + cpu.cfs_period_us (v1), compute ceil(quota / period). "max" and -1 quotas mean "no limit, fall back to sysconf".
2. Memory: read <root>/memory.max (v2) or <root>/memory/memory.limit_in_bytes (v1). "max" is unlimited; cgroup v1's near-ULLONG_MAX sentinel (PAGE_COUNTER_MAX) is also treated as unlimited.
3. Safety clamp: both axes take min(cgroup, host), so a mis-mounted cgroup that reports something bigger than the host can't push us above true hardware.
4. Fallback: missing cgroup files → host values, exactly as before. Bare-metal hosts and non-Linux platforms are unchanged.

The helpers live in a new internal header src/foundation/system_info_internal.h (same pattern as the existing pipeline_internal.h) so tests can drive them against a fake /sys/fs/cgroup tree without depending on the runtime environment.

Why this matters

Symptoms in the downstream consumer (sast-ai-app) before the workaround landed:

• Pod with limits.memory: 2Gi on a 32-core node spawned 32 indexing workers.
• Each worker's mmap window scaled with host RAM rather than the cgroup cap.
• Result: OOMKilled mid-index, watcher restart loop, 20Gi PVC grew anyway.

Operationally this was patched downstream by quadrupling pod memory and pre-creating PVCs at 4× the size CBM "thought" it needed. With this PR, the cgroup limits flow through cbm_default_worker_count naturally and the over-provisioning disappears.

Test plan

11 new Linux-only tests in tests/test_platform.c, each creating a fresh mkdtemp tree and exercising one detection path:

• cgroup_v2_cpu_quota — cpu.max = "200000 100000" → 2
• cgroup_v2_cpu_quota_rounds_up — cpu.max = "150000 100000" → ceil(1.5) = 2
• cgroup_v2_cpu_unlimited — cpu.max = "max 100000" → -1
• cgroup_v1_cpu_quota — cfs_quota_us/cfs_period_us = 200000/100000 → 2
• cgroup_v1_cpu_unlimited — cfs_quota_us = -1 → -1
• cgroup_no_cpu_files — empty tmp dir → -1
• cgroup_v2_mem — memory.max = "2147483648" → 2 GiB
• cgroup_v2_mem_unlimited — memory.max = "max" → 0
• cgroup_v1_mem — memory.limit_in_bytes = "1073741824" → 1 GiB
• cgroup_v1_mem_unlimited_sentinel — memory.limit_in_bytes = "9223372036854775807" → 0
• cgroup_no_mem_files — empty tmp dir → 0

Local verification

Verified on macOS (Apple Silicon, clang 17). The 11 Linux tests are #ifdef __linux__-guarded and skipped on macOS, so end-to-end Linux validation lives in upstream CI.

• Build (scripts/build.sh, -Wall -Wextra -Werror): clean, 47s.
• Test (scripts/test.sh): 3553 passed, 1 failed. The single failure is search_code_multi_word in tests/test_mcp.c:694 — already failing on plain upstream/main at the same SHA, unrelated to this PR, also showing up on recent nightly soak failures.
• Lint (clang-format + cppcheck): clean on all three touched files. (The remaining clang-format diff at system_info.c:97/99 is in BSD code I didn't touch; it reflects an Apple clang-format 17 vs. CI clang-format disagreement that exists on upstream/main already.)

Files

• src/foundation/system_info.c — new cgroup helpers; detect_system_linux rewritten with the safety clamps. macOS/BSD/Windows paths untouched. (+117/-6)
• src/foundation/system_info_internal.h — new internal header declaring the cgroup helpers for tests. (+44)
• tests/test_platform.c — 11 new Linux-only tests + small tmp-dir/fixture helpers. (+179)

Relationship to #364

These two are deliberately independent:

• This PR (Linux: cbm_system_info / cbm_default_worker_count don't respect cgroup CPU/memory limits #363) gives CBM the right default in containers.
• feat(platform): CBM_WORKERS env override for cbm_default_worker_count #364 (CBM_WORKERS env override) lets operators force a specific value when they want to leave additional headroom below the cgroup cap (or above it, on bare metal).

If both land, the precedence is: CBM_WORKERS env > cgroup auto-detect > host fallback, which matches the precedence shape we use for other CBM_* knobs.

[DeusData]

Thank you, @yangsec888! 🙏 This is excellent, thorough work — the cgroup-awareness is exactly what containerized deployments need, and I appreciated the care in the details:

• Handling both cgroup v2 (cpu.max, memory.max) and v1 (cpu.cfs_quota_us/cfs_period_us, memory.limit_in_bytes), including the v1 near-ULLONG_MAX unlimited sentinel.
• The min(cgroup, host) guard against mis-mounted cgroups reporting more than the host.
• The bounded read_small_file helper and the internal-header split so the parsers can be unit-tested against a fake cgroup tree — the 11 table-driven tests are great.

Two small things I adjusted while landing (both noted for transparency): the test additions were unioned with the CBM_WORKERS tests from #364 since they touched the same SUITE, and I replaced the test-teardown system("rm -rf -- '...'") with a shell-free opendir/unlink/rmdir recursive remove — it was safe in practice (the path is mkdtemp output) but I prefer not to spawn a shell from the test binary. The detection logic itself is entirely yours.

Landed in a5a3d1d, crediting you as author. Together with #364 this closes #363. Verified locally: build clean, all 3,622 tests pass (cgroup tests are #ifdef __linux__ so they run in Linux CI). Thank you for the deep container fix! 🙏