fix(core): authenticate runtime control message senders

[jrusso1020]

The runtime control bridge accepts any window's message when its payload claims hf-parent. A sibling or unrelated frame can therefore send playback, volume, seek, runtime-data, or other supported controls. Require the browser-provided sender to be the runtime's actual parent or its own window before inspecting or dispatching the control payload (#649).

Parent-to-composition controls and same-window controls remain supported, including embedded and standalone use. Existing payload/protocol validation is unchanged. Synthetic integration fixtures now include their legitimate parent sender instead of omitting MessageEvent.source.

Validation: full workspace build; all 2,703 core tests; core and runtime typechecks; lint/format; Fallow (no changed-file findings). The foreign/null sender regression fails against the original bridge. A real Chromium test with two sibling frames confirms parent and self controls are accepted while a foreign sibling is rejected. Unit coverage also distinguishes the embedding parent from the runtime window. No workflow changes or suppressions.

This follows the Studio sender batch but covers the opposite control direction. Other slideshow/playground handlers have different sender contracts and remain separate pending audit. Please independently review sender compatibility and #649's PR CodeQL result; closure is counted only after merge and main verification.

[miguel-heygen]

Reviewed exact head 9efedf769f4739c4c9d30302288973cad48673f1.

packages/core/src/runtime/bridge.ts:126 puts browser-controlled sender identity ahead of every payload/protocol/action branch. The accepted set is correct for the runtime contract: the direct embedding parent covers Studio and <hyperframes-player>, while window preserves standalone/self control; foreign siblings, grandparents, nested frames, and null sources cannot dispatch. Cross-origin/sandboxed parents still work because WindowProxy identity comparison does not require origin access.

bridge.test.ts:36-76 pins foreign/null rejection and distinct-parent/self acceptance, and the existing init fixtures now supply the legitimate parent source. The sibling slideshow navigation listener is a materially different bare-message embed contract with its own open alert #634, so keeping it for a separate audit is appropriate.

Verification: focused bridge + init suites pass 132/132 locally; changed-file oxlint/oxfmt and git diff --check pass. All six required checks, Windows render, and full Test are green. Exact merge-ref CodeQL analysis 1748384953 reports zero results and there are zero open PR-ref alerts, so #649 is code-fixed without dismissal.

— Magi

Verdict: APPROVE
Reasoning: The bridge now authenticates the only legitimate browser senders before any control side effect, preserves all production and standalone paths, and is fully green at the reviewed head.