fix(studio): block element selection while composition is loading

[miguel-heygen]

Summary

• Block element selection and hover highlighting in the preview while the composition is loading. compositionLoading state is forwarded from NLELayout → App.tsx via a new onCompositionLoadingChange prop.
• Reverts motion panel and manual drag editing defaults to false — these were accidentally set to true during the PR fix: alpha preview e2e fixes — exports, init templates, EPIPE crash #693 merge conflict resolution.

Test plan

• 472 studio tests pass
• Typecheck clean
• Pre-commit hooks pass

🤖 Generated with Claude Code

[vanceingalls]

Post-merge advisory review (this PR is already merged into next). Findings flagged for follow-up, not gating.

Verdict — Approve, but this PR exposes a process gap worth flagging.

The actual behavioral change is correct: suppress preview selection/hover while composition is loading. The revert of the Motion + manual-drag defaults to false is also correct (they were never supposed to be on by default).

Follow-ups

1. The defaults revert is the second time these flags flipped in 24 hours. PR #693 set them to true, this PR sets them back to false. Reason: that's two product-state changes for STUDIO_MOTION_PANEL_ENABLED and STUDIO_PREVIEW_MANUAL_EDITING_ENABLED in a single day's stack. Worth a process question: should alpha feature-flag defaults require an explicit dedicated PR (not buried in unrelated commits)? The "accidentally set during merge conflict resolution" pattern is hard to catch in review.

2. onCompositionLoadingChange is plumbed through NLELayout → App.tsx via a new prop and useEffect. This effect fires whenever compositionLoading flips. Good. But there's no test for the prop callback firing in NLELayout.test.ts. Reason: silent regression risk — if a future PR removes the useEffect or changes when setCompositionLoading fires, selection-blocking will silently stop working and the loading-overlay-but-still-selectable bug returns.

3. Selection-blocking is gated on compositionLoading from NLELayout, but PR #707 commit 2 expands this to also include showAssetOverlay. That's a follow-up gap: this PR's protection only covers composition-readiness, not asset-readiness. Worth confirming the PR #707 fix made it all the way (verified in the Player.tsx diff: onCompositionLoadingChange?.(showCompositionOverlay || showAssetOverlay) — yes it did).

Important

• The PR body is 3 lines. For a fix that ships a behavior change plus a defaults revert, the body should explicitly call out the second commit. Reason: makes the audit trail clearer for the auditor (or for Vai 6 weeks later) trying to understand why defaults flipped.

Nits

• "472 studio tests pass" — would be even more useful with a count delta vs. main (i.e. "added 0 tests").

Praise

• The fix is correctly scoped: prop callback up, two handler guards in App.tsx. No spurious refactoring.
• Catching the accidental defaults flip from #693 within 2 hours is exactly the right responsiveness.

— Vai