Serve staged binary assets during visual-compare source capture

[chubes4]

Problem

wordpress.visual-compare can load staged source HTML/CSS from the Playground preview, but binary image files staged beside them fail to render. This corrupts the source side of visual parity and attributes infrastructure loss to the transformer/candidate.

Observed in the Fisiostetic .fig matrix run:

• source URL: /wp-content/uploads/static-site-importer-fixture-matrix/fisiostetic/source/index.html
• final source URL: http://127.0.0.1:46779/wp-content/uploads/static-site-importer-fixture-matrix/fisiostetic/source/index.html
• source diagnostics: 26 images total, 15 loaded, 11 failed
• the 11 failures are exactly the 11 local Figma PNG/JPEG assets
• mounts.json records all 11 as staged-file mounts under the matching /wordpress/wp-content/uploads/.../source/assets/ paths
• mounted-files.json captures the under-1 MiB binaries with byte sizes and SHA-256 hashes; larger binaries are omitted only from evidence capture by the documented 1 MiB limit
• the same generated index.html, style.css, and assets render all 11 images in ordinary Playwright Chromium: every request is HTTP 200 with the correct image MIME type and nonzero naturalWidth/naturalHeight
• removing loading="lazy" from the generated source produced an identical broken WP Codebox screenshot, ruling out lazy loading

This became visible after Static Site Importer PR #655 intentionally moved source capture to the same WordPress runtime so staged source SVGs can resolve the generated self-contained font stylesheet. Falling back to host file:// capture would regress that contract.

Expected

Binary files supplied through inputs.stagedFiles and materialized under /wordpress/wp-content/uploads/... are byte-identical and HTTP-readable from the preview origin during browser commands.

Acceptance

• Add an integration test that stages a real PNG or JPEG plus HTML under /wordpress/wp-content/uploads/..., navigates through the normal preview URL, and verifies HTTP success, nonzero intrinsic image dimensions, and painted screenshot pixels.
• Cover a binary larger than the mounted-artifact evidence limit so evidence-retention policy cannot affect runtime materialization.
• Surface bounded failed image URLs/statuses in visual-compare diagnostics when source assets fail.
• Rerun the Fisiostetic source capture with 0 failed raster images.

Evidence

Blocks Engine issue with the disproven lazy-loading hypothesis and correction: Automattic/blocks-engine#666 (comment)

Affected WP Codebox code paths:

• packages/cli/src/commands/recipe-runtime-setup.ts (staged-file.mount, input.materialize)
• packages/runtime-playground/src/mount-materialization.ts (materializePlaygroundStagedInputs)
• packages/runtime-playground/src/browser-visual-compare.ts (source capture and image diagnostics)

The current binary materialization tests validate PHP file_get_contents(), but do not validate that the mounted binary is HTTP-served and browser-painted through the preview used by wordpress.visual-compare.

AI assistance

• AI assistance: Yes
• Tool: OpenAI GPT-5.6 Sol via OpenCode
• Used for: Evidence collection, source/candidate isolation, and ownership analysis.

[chubes4]

Fixed in #1939.

Focused Linux Lab verification against the original Fisiostetic failure:

• source images: 26 loaded, 0 failed (previously 15 loaded, 11 failed)
• candidate images: 17 loaded, 0 failed
• both capture readiness states: ready/high confidence
• visual mismatch improved from 19.58% (1377921/7036160) to 11.90% (837041/7036160) with no Blocks Engine or SSI changes

This confirms the missing 7.68 percentage points were preview infrastructure loss. Remaining differences are real source/candidate geometry.