Unify Style Editor schema definition: use content type tab as single source of truth for headless and traditional pages

[dario-daza]

Description

Currently, the Style Editor supports two Style Editor Schema definition paths — Headless and Traditional — but schema definition works differently for each:

	Headless	Traditional
Schema defined in	Code generated schema; uses registerStyleEditorSchema in the FE	Content Type tab UI (behind FEATURE_FLAG_UVE_STYLE_EDITOR) uses registerStyleEditorSchema in the BE

This dual approach creates inconsistency and maintenance overhead. The goal is to establish a single source of truth for Style Editor schema definition: the content type tab visual approach.

How it works today

The schema defined via the Content Type tab is saved in the Content Type metadata. Both headless and traditional pages already have access to this metadata. registerStyleEditorSchema is the internal mechanism used in both modes to register the schema at runtime.

What needs to change

The Style Editor schema resolution logic should:

1. Always prefer the schema defined in the Content Type tab (stored in Content Type metadata) — for both headless and traditional pages.
2. Create a new endpoint to retrieve the Style Editor Schemas defined for Headless approaches, the it requieres an auth token in order to work correctly.
3. Update the "no schema" documentation/message to reference the content type tab as the unified approach.

The feature flag FEATURE_FLAG_UVE_STYLE_EDITOR_FOR_TRADITIONAL_PAGES has been deleted and now we are using just the FEATURE_FLAG_UVE_STYLE_EDITOR to enable/disable the Style Editor for Traditional and Headless.

Priority behavior

Content type tab schema  →  wins (highest priority)
Code-based schema        →  moved to internal usage now the only source of truth are the schemas defined in the Content Types tab

Acceptance Criteria

• Schema defined via the content type tab is used as the Style Editor schema for both headless and traditional pages that use that content type.
• Style Editor end-user behavior (rendering, editing experience) is unchanged in both headless and traditional pages after this change.
• Headless pages whose content type has a schema defined in the content type tab render Style Editor using that schema.
• The existing "no schema configured" information message/documentation is updated to reference the content type tab as the unified way to define Style Editor schemas.
• The feature flag FEATURE_FLAG_UVE_STYLE_EDITOR is the only one FF that gates the Traditional and Headless Style Editor experience.

Additional Context

• The new endpoint that shows up the schema definition for Headless needs an Auth token.
• Internal schema registration mechanism (registerStyleEditorSchema) is not removed — it is still used internally to register schemas from either source.

[github-actions]

PRs linked to this issue

• refactor(style-editor): restructure style editor schema handling and … by @KevinDavilaDotCMS

PRs linked to this issue

• Create new endpoint for expose style editor schemas by @dario-daza
• refactor(style-editor): restructure style editor schema handling and … by @KevinDavilaDotCMS

PRs linked to this issue

• Create new endpoint for expose style editor schemas by @dario-daza
• fix(style-editor): Now the style editor form is showed in UVE by @KevinDavilaDotCMS
• refactor(style-editor): restructure style editor schema handling and … by @KevinDavilaDotCMS