Each look records whether its page scrolls sideways and how many screens tall it is, and the pull's looks name any phone page that scrolls sideways #9249

Whether a page fits one 390 px screen (#9212, #8971, #8970) is a fact the forge can measure, not a builder's screenshot. The looks service already reads layout entries back over DevTools after load. This adds the page's own size to what it records, so a pull shows the answer without anyone holding a phone.

Done looks like:

• [ ] The script installed by src/looks/capture.ts also records, after load, document.documentElement.scrollWidth, scrollHeight and the viewport's innerWidth/innerHeight. parseRecorded validates them as whole non-negative numbers and treats a missing one as absent, never as a failure.
• [ ] A look is stored with sideways: scrollWidth > innerWidth and screens: scrollHeight / innerHeight, rounded to one decimal, beside its LCP and layout shift (src/looks/service.ts).
• [ ] Where a pull's looks are listed, a phone look that scrolls sideways is named in one plain line ("/preview-admin/sample/held scrolls sideways at phone width"), with no banner and no red. A page that fits says nothing.
• [ ] Tests cover:

- parseRecorded with the new fields, with them missing, and with them malformed; - the stored look's sideways and screens; - the one-line notice being present for a sideways phone look and absent otherwise. Each fails without the change.

• [ ] Comment on #9240 with the held and bets phone looks' screens from this pull's own preview.

Files: src/looks/capture.ts, src/looks/service.ts, test/looks.test.ts. Risks: one picture at a time stays the rule. Do not add a browser start or a second navigation. Do not touch src/http/api.ts.

Parked by the crew: the check stayed red through 2 automatic tries (pull #9256 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check stayed red through 2 automatic tries: check failed: stopped: used 8775 MiB of memory, over its 8192 MiB limit (forge.json limits.memory) (pull #9264 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #9256 closed)
2. the check stayed red through 2 automatic tries: check failed: stopped: used 8775 MiB of memory, over its 8192 MiB limit (forge.json limits.memory) (pull #9264 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Split. It went red twice, once over the check's 8 GiB memory limit, because one run carried three changes: capture, storage, and the summary line. It is now #9319, where capture records the page's size and parseRecorded validates it, with one small test file and no browser, and #9320, where the check summary's vitals table names a phone look that scrolls sideways and shows each look's screens. #9320 waits for #9319, and #9320 also carries the comment on #9240.