A check never trips its own CPU guard: test shards follow the cell's CPU limit, not the host's #2257

Replaces #2243 (a person's ask). Both tries were red on "two forges in one process keep their own error and refusal signals". That test reads the check machine's real disk (10% free), not anything this changes. #2248 fixes it, and this waits for it.

Why: shardCount in scripts/test-shards.ts starts from availableParallelism(), which inside a cell can report the host's CPUs (80 on the vxrail) while forge.json gives a check cpus: 16. The guard then kills the check (used 16.1 cores for 30s, over its limit of 16).

Done looks like.

• [ ] The check receives its cell's CPU limit as an env var (e.g. FORGE_CELL_CPUS, from forge.json's check limits), set where the check cell is started.
• [ ] The shard count is min(that limit − 1, SHARDS_MAX, the number of test files), and at least 1. With no limit set it behaves as today.
• [ ] Test: shardCount with FORGE_CELL_CPUS=4 on a many-core host gives at most 3 workers; unset, it is unchanged.
• [ ] The pull states the check's peak cores before and after, from the run's own numbers.

Files. scripts/test-shards.ts (and scripts/shards.ts if the cap lives there), where the check cell's env is built (src/checks/service.ts or src/apps/contain.ts), one test.

Before pushing. bun x tsc --noEmit and the shards test.