[IMP] Bound the CPU, memory and time of an indexing pass

[moylop260]

Why

Left alone the indexer sizes itself against the whole machine. Measured inside a Vauxoo
container on an 18 GB MacBook (Docker Desktop VM of 11.9 GiB):

codebase-memory-mcp cli --index-worker    428% CPU    9.0 GB RSS  (73.9% of the VM)
container irc190_01:  NanoCpus=0  CpuShares=0  Memory=0

That is every core the container can see and three quarters of the VM, which leaves the laptop
swapping (kernel_task at 287%, 128 MB free). Containers are normally started with no cgroup
limit at all, so nothing below this tool stops it either: docker update --cpus=5 from the
outside is a patch, the contention has to come from here.

What

Every indexing pass now gets a quarter of the machine. Each value is resolved from the command
line first, then from an already exported CBM_* variable, then from the machine, and the
resolved value and its source are logged:

workers=1 source=default usable_cpus=5
memory_mb=2816 source=default total_ram_mb=11264 enforce=yes
index_worker_timeout_s=7200 source=default

Flag	Handed to the child as	Default
--workers N	CBM_WORKERS	a quarter of the usable CPUs, never below 1
--max-memory-mb N	CBM_MEM_BUDGET_MB and the enforced cap	a quarter of the usable memory, never below 512 MB
--index-timeout N	CBM_INDEX_WORKER_TIMEOUT_S	7200 (two hours)
--no-enforce-memory	—	off: the cap is enforced

"Usable" means what the container may use, not what the host has: the cgroup CPU quota and
the cgroup memory limit, falling back to the CPU affinity mask and /proc/meminfo. On the
measured container docker update --cpus=5 reads back as 5, where os.cpu_count() keeps
reporting 10.

The memory cap is enforced here, not by the environment variable

CBM_MEM_BUDGET_MB is not a cap, and setting it would not have delivered what was asked.
It only tells codebase-memory-mcp when to log mem.pressure and purge its allocator — the run
above reported mem.init budget_mb=2986 total_ram_mb=11946 source=ram_fraction and still
reached 9.0 GB RSS. Reading codebase-memory-mcp 0.9.1-rc.1 confirms it: src/foundation/mem.c
tracks RSS and warns, it never enforces, and none of the 45 CBM_* variables bounds it.

The portable OS mechanisms do not fit either:

• RLIMIT_AS / RLIMIT_DATA count the address space mimalloc reserves without ever touching
  it, so the pass would die well below its real usage.
• RLIMIT_RSS is a no-op on Linux.
• Writing to the cgroup needs privileges a container running as odoo does not have.

So the cap is enforced from the parent: the RSS of the child process tree is sampled while
the pass runs — the parsing happens in the --index-worker child, so watching only the process
this tool started would miss it — and the tree is killed (SIGTERM, then SIGKILL after a grace)
when it crosses the limit:

memory_cap_exceeded rss_mb=3012 limit_mb=2816 processes=2; killing the pass
Batch 3: the indexing pass reached 3012 MB, over the 2816 MB cap. Lower --batch-size so each
pass parses fewer modules, or raise --max-memory-mb when the machine can afford it

Recovery is the mechanism this tool already ships and documents: the batches are cumulative, so
everything indexed so far stays in the graph and a smaller --batch-size picks up from there.
The tree is signalled member by member instead of through its process group on purpose — putting
the pass in a session of its own would stop Ctrl-C from reaching a run that takes hours.

Verified

• 83 tests pass (pytest), pre-commit run --all-files clean.
• Readers checked against the real container irc190_01, not only mocked: cgroup_cpu_quota
  returns 5.0 for the --cpus=5 applied to it, cgroup_memory_limit 11811160064,
  default_workers 1, default_memory_mb 2816.
• The watchdog checked there too: a parent + a growing grandchild, cap 200 MB →
  memory_cap_exceeded rss_mb=206 limit_mb=200 processes=2, the grandchild released its memory,
  and the single-process case returns in 1.13 s.

Worth a second opinion

• Defaults are conservative on a limited container. With --cpus=5 in place, a quarter is
  workers=1. That is what "a quarter" means and it is one flag away, but it is slower than the
  status quo — say so if the fraction should have a floor above 1.
• A cap that fires is a failed pass. Today the run takes the machine down instead; this turns
  that into a bounded, explainable failure with a documented way forward. It is still a
  behaviour change for anyone whose instance legitimately needs more than a quarter of RAM.
• Sampling every 5 s can let a very fast allocation overshoot the cap before the next sample.

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️