A small forge is not stopped for CPU in its first minutes: the looks job retries a failing picture about once a second and drives it to 3.1 cores #11509

Evidence (host log, 0.7.537, forge probe-qzkd, size small = 1 CPU).

16:24:06Z [looks] no picture app=page-says env=production page=/ kind=phone theme=dark error="no picture: the browser showed an error page instead of the app (net::E…"
16:24:07Z [looks] no picture … kind=desktop theme=dark …
16:24:08Z [looks] no picture … kind=phone theme=light …
… (one about every 0.8 s, all five kinds, repeating)
16:24:32Z [forge] child forge stopped name=probe-qzkd why="used 3.1 cores for 30s, over its limit of 1"
16:24:36Z … crew is up … (restarted) and the looks loop resumes at once

A person's forge is killed and restarted within two minutes of their first app, by the forge's own screenshot job looping on a page that is not answering yet. This is also the likely source of the "restarts=4 unclean=4" seen on 2026-11-10 (#11155).

What.

• Looks: a failed picture is not retried in a loop. Wait until the app answers its health check, then try once per kind; on failure back off (e.g. 30 s, 2 min, 10 min) and give up with one line. Never more than one browser at a time on a forge of size small.
• Find why the browser gets an error page for an app that answers 200 from outside within 3 s (the cell's own route to <app>--<forge> or its egress rules), and fix it so the picture is taken.
• Background jobs on a cell (looks, checks, snapshots) run under a CPU share below the cell's limit, so the forge's own housekeeping can never get it stopped. The stop for "over its limit" names the process that used the CPU.
• A forge younger than ten minutes is throttled, not stopped, for CPU.

Acceptance. A test on a 1-CPU cell with an app that never answers: looks makes at most five attempts in the first minute, CPU stays under the limit, and the cell is not stopped. Production probe after release: a new small forge with one app shows no child forge stopped line in its first ten minutes.