fix: improve iOS bridge stability

[dcalhoun]

What?

Ensure the iOS native-to-web bridge is fully initialized before signaling editor readiness, and guard all JS bridge calls against early invocation.

Why?

Fix CMM-2008. Fix CMM-2009.

The onEditorLoaded signal was firing (via IntersectionObserver) before window.editor.* methods were assigned in the useHostBridge React effect. When native iOS code called bridge methods immediately after receiving the signal — e.g., getTitleAndContent() during an autosave triggered by opening the block inserter — the methods were undefined, causing TypeErrors (CMM-2008) or ReferenceErrors (CMM-2009).

How?

JS side

• Replace the standalone IntersectionObserver in use-editor-visible with a new useEditorReady hook that coordinates two conditions before dispatching onEditorLoaded:
  1. All window.editor.* bridge methods have been assigned (signaled by useHostBridge via a markBridgeReady callback)
  2. The editor content element is visible in the viewport (via IntersectionObserver on the VisualEditor/TextEditor root element, received through forwardRef)
• Use a callback ref in useEditorReady so the IntersectionObserver attaches when React mounts the editor content — not on initial render when the element doesn't exist yet.
• Defer editorLoaded() by one frame via requestAnimationFrame so the browser has painted the editor content before the native host starts the fade-in animation.
• Fix missing window.editor.focus cleanup on unmount.

iOS side

• Add isReady guards to undo(), redo(), dismissTopModal(), isCodeEditorEnabled, appendTextAtCursor(), getContent(), and getTitleAndContent(). Previously only setContent() was guarded.
• Reset isReady to false in controllerWebContentProcessDidTerminate so bridge calls are blocked until the editor re-emits onEditorLoaded after a WebView process crash.
• Fire-and-forget methods silently return when not ready. Async throwing methods throw EditorNotReadyError.

Tests

• Add use-host-bridge tests verifying window.editor.* methods are assigned and markBridgeReady is called, and that all methods are cleaned up on unmount.

Test infrastructure (first two commits)

• Consolidate @wordpress mock stubs into __mocks__/ directory.
• Remove unnecessary vi.mock() calls from existing tests.

Testing Instructions

1. Open the editor on iOS and immediately tap the "+" block inserter button.
2. Verify the inserter opens without a crash or error message.
3. Verify the editor loading indicator dismisses at the right time and the WebView content is visible when it fades in (no "pop" or flash).
4. Open a new empty post and verify the post title input is auto-focused with the keyboard visible.
5. Open the editor normally and verify all editing functionality works (undo/redo, block insertion, code editor toggle).

Accessibility Testing Instructions

N/A — no UI changes.

Screenshots or screencast

N/A

[kean]

Looks great.

[kean]

Does it actually happen? If yes, it might be worth saving it as "pending update" and applying automatically when the editor is ready. Not sure if it's worth it though. If there is a spinner, and you hit Cmd+V via the keyboard, you probably wouldn't expect it to work.

[dcalhoun]

No, I did not observe any reports of this occurring nor did I produce it. The guard was applied universally to avoid unexpected errors.

I agree. Stashing and later applying the pending update would be nice, but I'm not sure how realistic that being a real problem is currently. I'll likely defer that type of improvement until a problem surfaces.