Editor preview iframe drops elementorFrontend.config.elements.keys — every widget crashes with getElementSettings TypeError

### Description

Environment:
- Elementor: 3.33.0
- Elementor Pro: 3.33.1 (also reproduces with Pro deactivated)
- WordPress: 6.9.4
- PHP: 8.3.30
- Hello Elementor parent: 3.3.0
- Browser: Chrome (incognito, fresh, all extensions disabled)

Reproducer: open any existing page in Elementor editor.

Symptoms:

In editor preview iframe, every widget on the page crashes during init:
Uncaught TypeError: Cannot read properties of undefined (reading 'inner-container')
at GlobalHandler.getElementSettings (frontend-modules.min.js?ver=3.33.0:1:47469)
at GlobalHandler.getCurrentDeviceSetting (frontend-modules.min.js?ver=3.33.0:1:48026)
at GlobalHandler.getAnimation (frontend.min.js?ver=3.33.0:1:10850)
at GlobalHandler.onInit (frontend.min.js?ver=3.33.0:1:10971)

Same error pattern repeats for every widget type on the page: inner-container, container, image-box, heading, text-editor, button, icon-list,
video, html, image, gallery, nested-accordion. With Pro enabled, the same crash also routes through MotionFX.addCSSTransformEvents.

Root cause analysis (verified via reflection):

Frontend::get_init_settings() server-side correctly emits all three sub-fields. CLI test as admin user with is_preview_mode(3273) → true:

elements sub-keys=data,editSettings,keys
keys type=object (stdClass)
json output: {"data":{},"editSettings":{},"keys":{}}

But after editor init, the iframe's elementorFrontend.config.elements is missing the keys field entirely. From DevTools (parent editor, querying
iframe):

const ef = document.querySelector('#elementor-preview-iframe').contentWindow.elementorFrontend;
console.log({
hasConfig: !!ef?.config, // true
hasElements: !!ef?.config?.elements, // true
keysType: typeof ef?.config?.elements?.keys, // "undefined"
keysCount: Object.keys(ef?.config?.elements?.keys || {}).length, // 0
dataCount: Object.keys(ef?.config?.elements?.data || {}).length // 14
});

data is populated (14 element CIDs), but keys is gone. Some code in editor.min.js overwrites the iframe's elementorFrontend.config.elements with
a new object that includes data but does not preserve the keys property emitted by Frontend::get_init_settings().

getElementSettings in frontend-modules.min.js:1:47469 then accesses keys[type] where keys is undefined, hence the crash.

Eliminated as causes (verified in this order):
- ❌ Plugin/theme conflicts: Elementor Safe Mode active, default theme — bug persists
- ❌ Pro: deactivated — same crash via core GlobalHandler
- ❌ Plugin versions: tested 3.33.0/3.33.1, 3.33.1/3.33.1, 4.0.4/4.0.4 — identical crash
- ❌ Cache: CloudFront invalidated; tested in incognito; ?ver= strings match fresh JS
- ❌ Data corruption: _elementor_data parses as valid JSON; active kit (post 6) is published; _elementor_edit_mode set
- ❌ Browser cache: same in incognito and after Disable cache + hard reload

Reproducer environment: production WordPress site with Hello Elementor child theme, ACF Pro, Yoast SEO, Contact Form 7 — but bug reproduces with
all of those disabled via Safe Mode and child theme functions.php renamed.

### Steps to reproduce

1. Open Elementor editor for any existing page on the site (tested on pages using both Elementor Canvas template and a custom
page-risk-report.php template — both reproduce).

1. Example: https://truvify.com/wp-admin/post.php?post=3273&action=elementor
2. Open browser DevTools → Console.
3. Observe: as soon as the preview iframe initializes its widgets, the console fills with Uncaught TypeError: Cannot read properties of
undefined (reading '') for every widget on the page (inner-container, container, image-box, heading, text-editor, button,
icon-list, video, html, image, gallery, nested-accordion, etc.). Stack trace consistently routes through:

GlobalHandler.getElementSettings (frontend-modules.min.js:47469)
GlobalHandler.getCurrentDeviceSetting (frontend-modules.min.js:48026)
GlobalHandler.getAnimation (frontend.min.js:10850)
GlobalHandler.onInit (frontend.min.js:10971)
4. Visual symptom in the editor: widget control bars (+ / − icons on each section/column/widget) appear as raw + and − text instead of icon-font
glyphs; some widget rendering bails out mid-mount, leaving sections that look "missing" or blank.
5. Public frontend renders correctly — the bug is editor-only, because the public frontend doesn't depend on
elementorFrontend.config.elements.keys (it uses pre-compiled per-page CSS).
6. Diagnostic in console (parent editor window) confirms keys is missing from the iframe's runtime config:

const ef = document.querySelector('#elementor-preview-iframe').contentWindow.elementorFrontend;
console.log({
hasConfig: !!ef?.config,
hasElements: !!ef?.config?.elements,
keysType: typeof ef?.config?.elements?.keys,
keysCount: Object.keys(ef?.config?.elements?.keys || {}).length,
dataCount: Object.keys(ef?.config?.elements?.data || {}).length
});
// Output: {hasConfig:true, hasElements:true, keysType:"undefined", keysCount:0, dataCount:14}
7. Independent verification that PHP server-side IS emitting keys — Frontend::get_init_settings() invoked via reflection in WP-CLI as logged-in
admin returns:

elements sub-keys=data,editSettings,keys
keys type=object (stdClass)
json: {"data":{},"editSettings":{},"keys":{}}

7. So the keys field IS present in the PHP-emitted elementorFrontendConfig. Something in editor.min.js overwrites the iframe's
elementorFrontend.config.elements when pushing element data, replacing the original object with a new one that omits keys instead of merging
into it.

### Expected behavior

1. No JavaScript errors during editor preview iframe initialization. Opening the Elementor editor for an existing page should not produce any
Uncaught TypeError in the browser console. GlobalHandler.getElementSettings, GlobalHandler.getAnimation, and (with Pro)
MotionFX.addCSSTransformEvents should successfully resolve their per-element-type setting lookups for every widget on the page.
2. elementorFrontend.config.elements.keys populated in the iframe. After the editor pushes element data into the preview iframe,
elementorFrontend.config.elements should contain all three sub-fields preserved from the PHP-emitted elementorFrontendConfig:
- data — populated with element model CIDs (currently works: 14 entries)
- editSettings — populated (currently works)
- keys — populated with the per-widget-type setting-keys schema (currently broken: undefined)

The diagnostic snippet should output:
{hasConfig:true, hasElements:true, keysType:"object", keysCount:>0, dataCount:>0}
3. Widget control bar (+ / − icons) renders as icon-font glyphs, not as literal + and - text characters. The eicons font and the editor's
section/column/widget controls should mount and display correctly.
4. All sections and widgets visible in the editor canvas. No mid-render bail-outs, no "missing" sections caused by getElementSettings throwing
during onInit.
5. Editor preview should match the public frontend output in structure (the public frontend already renders correctly — only the editor is
broken).
6. Behavior should be consistent regardless of page template — both elementor_canvas and custom PHP page templates should produce a working
editor preview. Currently both crash identically.
7. No regression after Elementor 3.33.0 or whatever release introduced this — the same site presumably worked in an earlier Elementor version
(the patches in editor.min.js we maintain locally — Widget.initSettings .data write and Widget.initEditSettings .editSettings write — exist
precisely because of related keys/settings-init issues that started appearing around Elementor 3.30+; this bug looks like a continuation of that
family).

──────────────────────────────────────────────────────

### Elementor System Info

```txt
Server Environment
Operating System: Linux
Software: Apache/2.4.66 (Amazon Linux)
MySQL version: MariaDB Server v10.5.29
PHP Version: 8.3.30
PHP Memory Limit: 512M
PHP Max Input Vars: 10000
PHP Max Post Size: 512M
GD Installed: Yes
ZIP Installed: Yes
Write Permissions: All right
Elementor Library: Connected
```

### Agreement

- [x] I confirm I have read and followed all the guidelines and instructions outlined in the Elementor Bug Report form.
- [x] I agree that my issue may be closed without further action if it doesn't meet all the requirements outlined in the Elementor Bug Report form.