fix(capture): show same-origin iframe content in screenshots (19.3.2)

[LucaB01]

Summary

• Problem: the screenshot capture cloned an <iframe> element but not its page. The renderer then loaded the frame's src without the user's session (a login page, or nothing), and frames written by script have no src at all. Dialogs and grids that apps draw inside iframes showed up as empty boxes. Replays were fine, because rrweb records same-origin frames.
• Fix (src/ScreenCapture.js): each same-origin frame's document now goes through the same capture as the page (masking and blocking rules, styles, images, nested frames) and is stored in the clone's srcdoc, which the renderer shows instead of loading src.
• Unchanged: cross-origin frames, frames still on their initial about:blank while loading src, and pages whose Trusted Types policy refuses a plain srcdoc keep src exactly as before.
• Also: canvases are detected by tag name, so a canvas inside a frame (another JS realm) is captured too.
• Release: version 19.3.2, CHANGELOG entry, npm run build output (build/, published/19.3.2/, published/latest/).

Testing

• 6 new tests in ScreenCapture.test.js (frame content and styles, nested frames, masking inside frames, src="about:blank" frames written by script, Trusted Types fallback, cross-origin and still-loading frames). Full suite: 32/32 suites, 571/571 tests.
• Real Chromium: captured a page with a dialog in a same-origin iframe plus a script-written grid frame, then loaded the capture the way the renderer does with the dialog's src pointed at a 404. Dialog and grid render from srcdoc.
• Old vs new capture of a page without iframes: identical HTML.

Notes

• Typed values, scroll positions and canvases inside frames need the matching screenshot renderer update (it restores them per srcdoc frame). Without it, frame content still shows, just without those.

🤖 Generated with Claude Code