[SPIKE] UVE: Removes `isClientReady` and Redefining Initial Loading State Handling

[!CAUTION]
Let's wait until the #30970 issue is solved and see if we still need this SPIKE.

Parent Issue

https://github.com/dotCMS/core/issues/30943

Overview

This spike aims to explore the feasibility of removing the isClientReady property and redefining how the UVE (User View Environment) manages the loading state of iframes or editors. The investigation will focus on identifying alternative methods to determine when the customer page or iframe is ready and to ensure a seamless user experience without breaking existing functionality.

Background

Initially, the isClientReady property was introduced for two main purposes:

1. To signal the UVE when the client is ready to remove the initial loading state.
2. To allow re-fetching of the page with custom properties if the user passes a custom query.

More details about the need for isClientReady can be found here: feat(UVE): Enable Editing Pages with Custom Query #29407.

Task

1. Research Objective:

   • Determine if it is possible to eliminate the isClientReady property in the UVE state.
   • While isClientReady may be removed from the UVE, the Angular side should continue listening to the CLIENT_READY event to avoid breaking changes for users in alpha versions.

2. Key Questions to Address:

   • How will the system determine when the iframe or customer page is ready to remove the UVE Initial loading state?
   • Is the isClientReady property necessary for both Traditional and Headless environments, or is it only relevant for Headless?
   • How will the UVE behave when transitioning between different sections (e.g., pages, templates, rules, experiments) and back? More details on this issue can be found here: fix(uve): Fixing infinite loading when re-entering to uve editor in traditional pages #30715.
   • Is the isClientReady property essential, or is there an alternative method to remove the Initial loading state?
   • How will this change affect customer implementations? Document the potential impacts.

3. Proof of Concept (POC):

   • Develop a POC with a reasonable solution to discuss with the team.

Documentation

• Document the findings of the spike, including any identified alternatives to isClientReady.
• Provide a detailed explanation of how the proposed solution will handle the loading state.
• Include any potential impacts on customer implementations and how to mitigate them.

Proposed Objective

Core Features

Proposed Priority

Priority 3 - Average

```[tasklist]

Acceptance Criteria

• Completion of the research with documented findings.
• A clear recommendation on whether to proceed with removing isClientReady.
• A POC demonstrating the proposed solution.
• Documentation covering the research findings, customer impacts, and potential alternatives.
• Team discussion and feedback on the proposed solution.
  \`

Start by reviewing the dependency on #30970, the UVE state and the Angular-side CLIENT_READY event, along with the linked work in #30943 and #30715. Done means a documented feasibility analysis, a recommendation on removing isClientReady, a POC for loading-state handling, and customer-impact notes.