Settings says what a sized forge's cores mean for builds (Compute, both doors) #11733

An admin of a sized child forge now sees a "Cores" row on /settings, and the terminal has a matching "Cores" screen with the same sentence. The new test file, the touched account, plan-row and CPU-rule tests, tsc, gate.ts and design-lint.ts pass. I did not run the full suite, because fast.ts listed 1,888 test files for this diff. I have not checked it on a sized child preview, which the issue asks for. I also did not use keep_plan; no such tool was available in this session.

• What it says: "1 CPU: builds run, slower." followed by how the forge is held to its cores. The sentence is written once in src/spawn/cores.ts and both doors print it.
• How it's decided: the forge reads its own state rather than assuming. A cpu.max quota in its cgroup says the kernel slows a busy build. Allowed CPUs no more than its cores say it is pinned, which also slows it. Neither says only the watch applies. For the watch the row states its cost, with the 5-minute and 10-minute figures read from src/apps/cpu_rule.ts.
• Where it shows: the row sits beside the Plan row via src/web/cores_row.ts. The terminal entry is src/tui/screens/cores.ts, registered in entries.ts. Only admins of a forge that is a cell child (FORGE_CELL_SIZE set) see either; others see nothing.
• Docs and tests: docs/features/cores-row.md, and test/cores-row.test.ts covers the three hold modes, the row's gating, the terminal render and a /settings fetch with and without a size.

I left out showing the row to non-admins and any change to how cores are held or enforced.

To try it, run a sized child, sign in as its admin, open /settings, and look for the "Cores" row. In the terminal, open the palette and pick "Cores".

The push needed a Try: line (pre-push refused without one), so I added an empty commit carrying it.

Closes #11694

An admin of a sized child forge now sees a "Cores" row on /settings, and the terminal has a matching "Cores" screen with the same sentence. The new test file, the touched account, plan-row and CPU-rule tests, tsc, gate.ts and design-lint.ts pass. I did not run the full suite, because fast.ts listed 1,888 test files for this diff. I have not checked it on a sized child preview, which the issue asks for. I also did not use keep_plan; no such tool was available in this session.

• What it says: "1 CPU: builds run, slower." followed by how the forge is held to its cores. The sentence is written once in src/spawn/cores.ts and both doors print it.
• How it's decided: the forge reads its own state rather than assuming. A cpu.max quota in its cgroup says the kernel slows a busy build. Allowed CPUs no more than its cores say it is pinned, which also slows it. Neither says only the watch applies. For the watch the row states its cost, with the 5-minute and 10-minute figures read from src/apps/cpu_rule.ts.
• Where it shows: the row sits beside the Plan row via src/web/cores_row.ts. The terminal entry is src/tui/screens/cores.ts, registered in entries.ts. Only admins of a forge that is a cell child (FORGE_CELL_SIZE set) see either; others see nothing.
• Docs and tests: docs/features/cores-row.md, and test/cores-row.test.ts covers the three hold modes, the row's gating, the terminal render and a /settings fetch with and without a size.

I left out showing the row to non-admins and any change to how cores are held or enforced.

To try it, run a sized child, sign in as its admin, open /settings, and look for the "Cores" row. In the terminal, open the palette and pick "Cores".

The push needed a Try: line (pre-push refused without one), so I added an empty commit carrying it.

The "pipeline first" rule failed because this pull adds a feature (the Cores row on /settings and in the terminal) and changes nothing in the pipeline. I added an empty commit with a Direction: line giving the reason, and pushed it. Running bun scripts/gate.ts locally printed nothing and the push went through. The forge's check has not re-run on this push yet, so I don't know its verdict.

The Direction: line says that a sized forge's builds die at the host's CPU stop (#11661), and operators can't see that limit anywhere. The Cores row makes it visible.

Nothing else in the code changed. I did not re-run tsc or the tests, because only a commit message was added.

Five of the six review points are done and pushed. Point 1, the hold until the pipeline is cleared, is not something I can settle. bun x tsc --noEmit is clean, design-lint reports nothing outside the system, and the touched tests pass. The new tests cover the quota and watch holds, not the pinned one, as in point 2 below.

1. Pipeline first. I can't show this issue is a pipeline blocker, and I added no pipeline change. The Direction: commit stays as the stated reason, and holding the pull is a call for a person.

2. Preview. The preview is still not a sized child, so /settings there shows no Cores row. I added a test that renders the full /settings page as an admin:

• Quota: it points FORGE_CELL_CGROUP_DIR at a temp cgroup holding a cpu.max with a quota and checks the kernel sentence.
• Watch: with no quota in cpu.max, it checks the watch sentence.
• Pinned: it is not tested on the page, because that hold reads the real /proc/self/status and can't be faked from a test. That hold is covered by the coresOf unit test, and the page test accepts either the watch or the pinned wording.
• Plain forge: with no size set, the row is gone.

3. Design. coresRow now emits a bare row. planRow takes it as an optional fourth argument and puts it inside its own dl, so there is one list and one hairline. When there is no Plan row, the Cores row gets its own dl.

4. Watch sentence. It now reads "Nothing limits this forge to its cores. A build that stays above twice its cores for 5 minutes is stopped; the first 10 minutes are safe." The numbers still come from cpu_rule.ts. I updated docs/features/cores-row.md to match.

5. Terminal gate. entry.run now refuses a non-admin, and coresScreen prints "Only admins see this." for one. A new test checks that run pushes nothing for a member and pushes the screen for an admin.

6. Clean. The row is computed above the return in account.ts, and CORES_LABEL is gone.

The header-width check failed because two comment lines ran past 160 columns. They were the header comment in src/web/cores_row.ts and the doc comment on planRow in src/web/plan_row.ts. I wrapped both and changed no code.

test/header-width.test.ts and test/cores-row.test.ts now pass, and bun x tsc --noEmit is clean. I pushed the fix, but the forge's check has not re-run on it yet.