feat(py): the construction-time sandbox gate and the worker's address-space limit

[jat255]

This PR adds protection_mode(), which decides before an agent is built whether this host can sandbox the code execution worker, and the 8 GiB address-space cap the worker puts on itself at startup. Nothing calls the gate yet; run_python registration wires it in.

Agent-written detail

sandbox_capabilities() is the shape the four ctypes probes fill in. Until they exist it reports every mechanism unavailable, so the gate refuses every host. That is why it is not wired into Commons.__init__ here: doing so now would abort construction everywhere, for a tool that is not registered yet.

Two departures from run_r_protection_mode(). The opt-in is COMMONS_ALLOW_UNSAFE_FALLBACK rather than an option, and there is deliberately no keyword for it, so accepting weaker protection takes an act outside the code. Only the address-space limit is set, not a CPU limit: RLIMIT_CPU is cumulative over the worker's whole life, so a long session would be killed mid-call rather than hit the parent's per-call timeout. Noted on kata t7d4.

A kernel that will not set RLIMIT_AS is reported rather than treated as fatal. Recent macOS is such a kernel, so the three clamp tests skip locally and run on the Ubuntu leg of CI.

roborev flagged the protection-mode decision table as a cross-language contract held twice, once per suite. Fixing it here would pull pkg-r/ into a Python-only task, so kata dkev, which already owns the shared sandbox fixture, has been widened to cover the table.