fix(engine): fail closed on blocked SRI scripts

[miguel-heygen]

What

Best-effort renders now fail closed when Chromium blocks a load-bearing script because its Subresource Integrity digest is stale. The failure reaches the existing sub_timeline_script_failure policy instead of degrading to static scenes under a non-fatal readiness timeout.

Why

Chromium returns HTTP 200 for the script and emits the SRI rejection only as a generic console error. The engine previously monitored request failures, HTTP failures, and HyperFrames-prefixed runtime errors, so this browser diagnostic was invisible even though the script never executed.

How

One console script-failure classifier now recognizes both existing composition runtime errors and Chromium’s exact blocked-integrity diagnostic. The classifier records a redacted stable failure ID through the existing deduplicated script-failure path. Authored integrity values and localized script bytes remain untouched.

Test plan

• Exact Chromium stale-SRI console diagnostic is classified as a script failure.
• Non-error and unrelated integrity messages remain ignored.
• Existing sub-timeline poll returns the fail-fast script-failure outcome.
• Frame-capture and sub-timeline suites pass (32/32).
• Engine typecheck, oxlint, and oxfmt checks pass.
• Documentation updated (not applicable).

[miga-heygen]

Clean, narrow classifier extraction. classifyConsoleScriptFailure preserves the existing HyperFrames-runtime-error priority path unchanged, and adds a new case that requires both type === "error" and a match on Chromium's exact blocked-integrity phrasing ('failed to find a valid digest ... integrity ...' AND 'resource has been blocked') before promoting to the existing deduplicated recordScriptLoadFailure fail-fast path. Tests confirm the exact Chromium diagnostic is classified correctly, and that non-error type / unrelated integrity text are correctly ignored (no false positives). CI green. LGTM.