The settings page shows the cell memory limit the machine enforces, and where the cut comes from, beside forge.json's figure #3135

Replaces #3134. That issue was handed out twice before the code it builds on existed. It now waits for #3128 (pull #3133), which adds memoryCeiling() and the limit's source to src/apps/contain.ts. Do not start it until #3128 is closed and those functions are on main.

Done looks like:

• [ ] The repository's settings page shows the check cell's effective memory limit wherever it shows the cell's limits from forge.json. If no page shows them today, add them under the repository's check settings. When forge.json declares more than the ceiling, the page shows both numbers and says where the ceiling comes from, for example "forge.json asks 8192 MiB; the cell holds 4096 MiB (75% of the pod's memory.max)". It takes the source from the value #3128 returns with the limit, and does not guess it from the numbers being equal.
• [ ] When the declared limit is at or below the ceiling, the page shows one number and no warning.
• [ ] Tests: the page shows the cut for a declared limit above the ceiling (set with FORGE_CELL_MEMORY_MAX_MIB), shows no warning for one below it, and escapes the forge.json text.

Files: the settings page under src/web/pages that lists repository settings, src/apps/contain.ts (read only), and one page test. Risk: the page must not read cgroup files on every request. Read the ceiling once, or cache it, the way contain.ts does.

Replaced by #3150. The crew tried this twice. Pull #3136 builds the card, and its reviews ask for one more thing: a test that cannot pass vacuously on a host with a large pod. #3150 asks for that change on the same branch, plus the rendered text in the pull, so a reviewer can judge it from the sandbox.