Recognize external editor presentation stylesheet identities

[chubes4]

Problem

Editor presentation capture only extracts blocks-engine-presentation:<sha256> identities from inline <style> content. It already records external canvas stylesheet URLs, but does not recognize an expected SHA-256 identity carried by an external stylesheet URL version.

This makes a bounded external-delivery migration appear to have missing editor styles even when every expected stylesheet is loaded. Automattic/blocks-engine#1478 demonstrates the gap: both solved fixtures have exact frontend visual parity, clean/ready editors, and all generated stylesheet URLs in the editor iframe, but generatedPresentationIdentities is empty and promotion reports missing_styles.

Evidence: https://github.com/Automattic/blocks-engine/actions/runs/33453527125

Expected contract

When captureEditorPresentation receives expected presentation identities, recognize an identity from an observed external stylesheet URL when its canonical content-hash version exactly matches one of those expected identities. Keep inline marker support and fail-closed expected-set comparison unchanged.

Acceptance

• External stylesheet URLs with an exact expected 64-hex content-hash version contribute that expected identity.
• Arbitrary URL versions and unrequested hashes do not become presentation identities.
• Inline blocks-engine-presentation:<sha256> markers continue to work.
• Browser capture tests cover external-only, mixed inline/external, unrelated hashes, delayed stylesheets, and complete expected-set observation.
• Blocks Engine solved-site promotion can prove externally delivered editor presentation without restoring large inline CSS.

AI assistance

GPT-5.6 Sol via OpenCode diagnosed the CI evidence gap, traced the WP Codebox capture implementation, and drafted this issue. Chris Huber reviewed and orchestrated the work.