fix: respect screenshot bounds on HiDPI displays

[shixi-li]

Fixes #2531

What changed

• factor the page's actual window.devicePixelRatio into screenshot downscaling
• keep CDP clip dimensions in CSS pixels while bounding the resulting bitmap dimensions
• add a regression test for the real defaultViewport: null path with a forced 2x device scale factor

Why

Screenshot source boxes and CDP clip dimensions are expressed in CSS pixels, but the returned bitmap is scaled by the page's device pixel ratio. The previous calculation compared the CSS width directly with screenshotMaxWidth, so a 2x page could return an image twice the configured bound.

The new calculation derives the clip scale from box × devicePixelRatio, making the limit apply to the image pixels sent to the model.

Validation

• npm run check-format
• npm run build
• npm run test -- tests/tools/screenshot.test.ts --test-name-pattern='honors screenshotMaxWidth at device scale factors above 1'
• npm run test -- tests/tools/screenshot.test.ts --test-skip-pattern='with full page resulting in a large screenshot'

The new regression fails on main with a 200px-wide image and passes with an exact 100px result after this change. I also attempted the full suite with retries; this local environment still times out in unrelated daemon/extension E2E tests and hits the existing Page.captureScreenshot: Page is too large case, which reproduces on pristine main.

[shixi-li]

Rebased again onto the latest main (0b4390d); the current head is c801c83. git range-diff reports the PR commit as unchanged. The two new upstream commits include the repository-wide verifyFilesSchema migration, which touches src/tools/screenshot.ts in a separate hunk; the rebase preserved both that new object-schema form and the HiDPI calculation without conflict. The introduced HiDPI regression test and the related no-viewport downscaling test pass on the current head. For transparency, the full screenshot file still hits Page.captureScreenshot: Page is too large in the pre-existing large full-page case; the identical command reproduced the identical failure on a detached clean origin/main, so no unrelated code change was made. The Memory leak tests, Check code before submitting, and Compile and run tests workflows are again action_required before creating jobs. Could a maintainer approve those runs and review the rebased PR when convenient?

[thomasbachem]

Diff looks right to me. The emitted bitmap is box * scale * dpr, so folding the ratio into the bound is the right place to fix it, and at a ratio of 1 the calculation is unchanged.

I pulled both versions of computeDownscaleClip() out and ran them over a matrix of box sizes, ratios and bounds. Nothing came back above the bound, nothing main clips stopped being clipped, and the sub-pixel guard fires on identical inputs either way since the ratio cancels out of it.

The new test also can't pass on main, which returns 200 where it asserts 100.

Still behind main, and the test jobs need a maintainer to approve the run.

[shixi-li]

Thanks for the independent validation. I rebased the unchanged patch onto the current main@fadbf41d; the new head is 5c93e0e, and git range-diff reports the commit as equivalent. npm run build and git diff --check pass. After syncing the locked dependencies, the two focused browser tests still stop before their assertions because local Chrome/Puppeteer closes during Target.setDiscoverTargets; I did not change the patch to mask that environment-level launch failure. The title, change scan, and CLA checks are green; the full test jobs still need maintainer approval when convenient.

[thomasbachem]

Re-checked the rebase. The patch at 5c93e0e is identical to the one I reviewed down to the context lines, with one hunk header shifted by two, so my review above still stands.

Worth knowing before those runs get approved: Compile and run tests has been red on main for its last 11 runs, the last green one being 0b4390d on the 13th. Every failure in that streak is a Windows or macOS cell, and the failing test moves around between them, mostly timing and navigation cases. No Ubuntu cell has failed once. So one of those cells going red here would not say much about the patch.