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.