feat(sdk-client): gate fetchStyleEditorSchemas on UVE edit mode to avoid unnecessary network calls

[dario-daza]

Description

fetchStyleEditorSchemas in libs/sdk/client/src/lib/client/page/utils.ts fires on every client-side client.page.get() call — including production/live/preview mode pages. The only guard today is the SSR check (typeof window === 'undefined').

registerStyleEditorSchemas (called downstream in @dotcms/uve) already returns early when not in UVE_MODE.EDIT, but by that point the network round-trip to /api/v1/page/{pageId}/contenttype-schema has already been paid.

Why it can't simply use getUVEState()

@dotcms/client intentionally does not depend on @dotcms/uve. Importing getUVEState() or UVE_MODE from @dotcms/uve would create a coupling violation.

Proposed fix

Add an inline iframe + mode check in fetchStyleEditorSchemas (same logic as getUVEState(), self-contained):

// Not in a UVE iframe context — schemas are irrelevant
if (window.parent === window) {
    return [];
}
// Not in edit mode — schema registration is a no-op downstream anyway
const uveMode = new URL(window.location.href).searchParams.get('mode');
if (uveMode !== 'edit') {
    return [];
}

This eliminates the wasted round-trip in production and preview mode without introducing a dependency on @dotcms/uve.

Long-term fix

Include schemas in the GraphQL page response (as noted by @rjvelazco in PR #35355) so no separate HTTP request is needed at all.

Affected file

core-web/libs/sdk/client/src/lib/client/page/utils.ts — fetchStyleEditorSchemas function (around line 280)

Acceptance Criteria

• fetchStyleEditorSchemas returns [] early when window.parent === window (not inside a UVE iframe)
• fetchStyleEditorSchemas returns [] early when the URL mode param is not edit
• No import of @dotcms/uve or getUVEState() is added to @dotcms/client
• Existing tests pass; new tests cover the early-return cases
• A code comment documents this as a known limitation pending the GraphQL inclusion fix (ref PR refactor(style-editor): restructure style editor schema handling and … #35355)

Additional Context

Identified during review of PR #35355 (style editor schema unification). The registerStyleEditorSchemas downstream guard already prevents side effects, but the HTTP request itself is wasted. This is a performance optimization, not a correctness fix.

[github-actions]

PRs linked to this issue

• include style editor schemas in the GQL response by @dario-daza