Container flex alignment fix
Fixes containers rendering with default alignment on the front-end despite `justify_content` / `align_items` values being persisted (#32).
Root cause
The MCP tool descriptions accepted `justify_content`, `align_items`, and `align_content` as container settings, but Elementor's container schema reads them under the prefixed keys `flex_justify_content`, `flex_align_items`, and `flex_align_content`. Values were saved under the wrong keys, so Elementor's CSS generator never emitted the corresponding `--justify-content` / `--align-items` custom properties — the container silently fell back to default alignment.
What changed
- New `Elementor_MCP_Element_Factory::normalize_container_settings()` helper remaps the unprefixed shorthand to Elementor's prefixed flex keys.
- Applied at element creation (`add-container`, `build-page`) and on partial-merge updates (`update-container`, `update-element`, `batch-update`).
- Update path only normalizes when the target element is a container — widgets like the Pro nav-menu, which legitimately use `align_items` as a widget-level setting, are unaffected.
- Factory auto-center default for column containers now writes the prefixed `flex_align_items` key.
- Tool descriptions for `add-container` / `update-container` now point to the prefixed keys, while still accepting the unprefixed shorthand for backward compatibility.
Tests
9 new regression tests in `tests/unit/regression/ContainerKeyAliasRegressionTest.php` pin the remap behaviour, including a test that asserts widgets are NOT remapped.
Upgrade notes
Recommended for anyone using `add-container`, `update-container`, `update-element`, `batch-update`, or `build-page` to control flex alignment. No data migration needed — the next save of any affected container will write the corrected keys.
Closes #32.