fix: use custom viewport dimensions in streaming frame metadata and image resolution

[jin-2-kakaoent]

Summary

• Use the viewport dimensions captured at screencast start for deviceWidth/deviceHeight in frame metadata, instead of CDP's Page.screencastFrame metadata which returns the physical device resolution regardless of viewport emulation
• Resize the browser content area via Browser.setContentsSize when viewport changes, so screencast captures frames at the correct resolution
• Restart active screencast when viewport dimensions change so maxWidth/maxHeight parameters are updated
• Pass viewport dimensions to --window-size at Chrome launch time via LaunchOptions.viewport_size, reducing reliance on the experimental setContentsSize at runtime
• Log setContentsSize failures via eprintln! instead of silently ignoring with let _ =
• E2E test verifying both metadata and actual JPEG image dimensions

Context

Fixes #1031. PR #952 fixed status messages and Page.startScreencast parameters to use the configured viewport, but two issues remained:

1. Frame metadata still used CDP's physical device dimensions (e.g., 1280x577 instead of the configured 1000x1000)
2. Frame image resolution was incorrect because Emulation.setDeviceMetricsOverride only changes the CSS viewport — screencast captures the actual browser content area, which was still at the default --window-size=1280,720

Test plan

• Manual reproduction with the script from the issue confirms deviceWidth/deviceHeight and image resolution now match the custom viewport
• Runtime viewport changes are reflected in subsequent frames
• Default viewport (no custom set) continues to work correctly
• E2E test e2e_stream_frame_metadata_respects_custom_viewport verifies both metadata and actual JPEG image dimensions (800x600)
• Existing E2E stream test continues to pass
• cargo check passes cleanly

[vercel]

@hyunjinee is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[ctate]

Thanks for this fix, @hyunjinee!

One note: Browser.setContentsSize doesn't appear in the official CDP docs — worth confirming it's stable across Chrome versions, or consider Browser.setWindowBounds as an alternative. Also, the silenced let _ = on that call means failures go unnoticed; a debug! log would help with future debugging.

Looks good overall!

[jin-2-kakaoent]

@ctate Thanks for the review!

Re: Browser.setContentsSize stability

Browser.setWindowBounds is also marked experimental: true in the CDP protocol, so switching wouldn't improve stability guarantees. Additionally, setWindowBounds sets the outer window size (including title bar/chrome), which requires platform-specific inset calculations to get the correct content area. setContentsSize targets the content area directly — a better fit for screencast resolution matching.

Re: let _ = silencing errors

Fixed — replaced with if let Err(e) + eprintln!. The daemon's stderr pipe is closed after startup, so a log crate subscriber wouldn't provide visibility either. eprintln! is visible during startup and in tests, matching the existing convention in the codebase.

Additional improvement

Added viewport_size to LaunchOptions so --window-size is set to the configured viewport at Chrome launch time. This reduces reliance on the experimental setContentsSize call at runtime — if it fails on an older Chrome, the initial viewport is still correct via the launch argument. Runtime viewport changes still use setContentsSize as there's no stable alternative.