[Bug] Campaign Gutenberg editor: "Classic" (freeform) block edit popup is an unusable thin strip on hard refresh

Campaign Gutenberg editor: "Classic" (freeform) block edit popup is an unusable thin strip on hard refresh — TinyMCE not initialized in the iframed editor

> Follow-up to my earlier report ["v3 email editor cannot open legacy v2 Classic/HTML templates"](https://community.wpmanageninja.com/portal/space/fluent-crm/post/v3-email-editor-cannot-open-legacy-v2-c). In 3.1.6 the legacy `_edit_type=html` template now opens (good - thank you!), but editing the resulting Classic / freeform block inside the campaign Gutenberg editor is broken on a cold load.

## Environment
- FluentCRM: 3.1.6
- FluentCRM Pro / FluentCampaign: 3.1.6
- WordPress: 7.0
- WooCommerce: 10.8.1
- PHP: 8.3
- Database: MariaDB 11.4
- Theme: Astra child
- Browser: Firefox (reproduced consistently)

## Summary

When editing a campaign in the Default (Gutenberg) editor that contains a Classic / freeform block (e.g. a legacy `_edit_type=html` newsletter), clicking the block's "Edit" opens the WordPress core `block-editor-freeform-modal` — but the editing textarea is a ~58px / 2-row thin strip (the modal frame itself is ~582px). The visual TinyMCE editor is not attached, so the block is effectively unusable for non-technical users.

It is load-order / timing dependent: on a warm/soft navigation TinyMCE sometimes attaches and the editor works; after a hard refresh (Ctrl+F5) it reliably breaks into the thin strip. This intermittency = a race condition.

## Root cause (diagnosed in-browser)

The FluentCRM block editor runs the content canvas inside an iframe. We instrumented the iframe's `window`:

- `window.tinymce` → loaded (TinyMCE v4 present), `window.wp.oldEditor` / `window.wp.editor` → present.

- BUT `tinymce.editors.length === 0` and `tinymce.get(\) === undefined` → no editor instance was ever created for the freeform block's textarea.

So the capability is fully loaded in the iframe, but the freeform block's `wp.oldEditor.initialize(...)` either does not run or runs before its dependencies are ready on a cold load → the bare `\` fallback remains (the "thin strip").

This is essentially the WP 6.x iframed block editor + Classic (core/freeform) block integration problem, surfacing in FluentCRM's iframed campaign editor.

## Reproduction

1. Have a campaign whose body is a Classic / freeform block (e.g. import a legacy `_edit_type=html` template), in Default (Gutenberg) editor mode.

2. Open the campaign editor.

3. Click the Classic block → Edit.

4. Ctrl+F5 (hard refresh), reopen Edit.

5. Observe: the "Classic Editor" modal opens but the textarea is a ~58px thin strip; the visual TinyMCE toolbar/content does not render. Editing is impractical.

## Impact

Non-technical newsletter editors cannot reliably edit a Classic-block campaign in the Gutenberg editor; the broken state appears unpredictably (after refresh). This was a major part of why we delayed the 3.x upgrade.

## Workaround we use

We switch such campaigns/templates to the dedicated "Classic Editor" (`raw_classic`) mode, which does not use the iframed freeform modal and works reliably. (See separate report on `raw_classic` mode not persisting on switch.)

## Expected

On a cold/hard load, the freeform block's "Edit" modal should initialize TinyMCE reliably (await `wp.oldEditor`/`tinymce` readiness in the iframe before initialize), or render a full-height fallback textarea instead of a 2-row strip.

## Attachments

- Screenshot: the "Klasszikus szerkesztő" (Classic Editor) modal with the ~58px thin-strip textarea after hard refresh.

- Browser console probe output (tinymce present, 0 instances on the textarea).