Bridge + optimistic-update layer. +378/-0 pure additive against the previous stack PR. Two things worth verifying explicitly before merge:

1. Cross-origin iframe access for the runtime bridge

The PR body says "Runtime bridge reads gsap.getProperty() from iframe for drag commits." If this is implemented via iframe.contentWindow.gsap.getProperty(...) or similar direct cross-realm access, it has the same fragility we hit on hf-internal#396 (useTimelinePlayer.ts) — same-origin coupling that breaks the moment any flow (CDN preview, sandboxed iframe, dev-server cross-port) puts the iframe at a different origin.

The cleaner long-term shape is postMessage with a typed protocol ({ source: "hf-studio-bridge", type: "getProperty", target, prop } → response message). Worth confirming which approach this PR took, and if it's direct contentWindow access, what the plan is for preview/CDN paths.

2. Optimistic update rollback semantics

The PR body promises "Optimistic cache updates roll back on failure" in the test plan. The two things to verify:

• Server returns 400/500: client cache reverts to pre-mutation state. No partial application.
• Server succeeds but returns a different result than predicted: cache reconciles to server-truth (last-write-wins, not optimistic-overwrites-server).

Race condition to look for: user fires mutation A (optimistic) then mutation B (optimistic) before A's server response. If A's response is "rejected", does B's optimistic state persist (correct) or get clobbered by A's rollback (incorrect — drops B)? The async pipeline + beforeReload/skipReload flags hint at a queue model; worth a test that covers the interleave.

3. skipReload flag

beforeReload and skipReload are new state flags. skipReload in particular sounds like it bypasses the normal reload-after-mutation refresh. Verify the cache stays consistent in that path — if the runtime bridge updates the live iframe directly and the server-side script is also updated, the next reload (if it does happen) should be a no-op. If the runtime and AST diverge silently, that's a hard-to-debug bug class.

I'd want to see at minimum one test that exercises: optimistic update → server success → skipReload → next reload → cache and DOM still match server-truth. If the test isn't there yet, worth adding.

Non-blocking observation

378 lines added with 0 deletions is a lot of new surface in @hyperframes/studio — anything exported from this PR becomes part of Studio's public API. Worth a check that internal helpers (the bridge plumbing, the async pipeline orchestration) are kept module-private with // @internal JSDoc where appropriate, and only the public useOptimisticGsapMutation-style hooks are exported.

Review by Jerrai (hyperframes specialist)