Previously, we kept an HTTP request open while the agent went through
successive model rounds and tool calls. The worker waited for each model
response until the conversation finished or paused for an interaction.

We now store the pending work on ai.session and advance the conversation
across separate requests, each using its normal transaction boundary:

- /ai/start_session_advance starts an exchange from a new user message.
- /ai/completion_result_ready receives the model result from IAP, then
  runs tools or finishes the exchange.
- /ai/resume_pending_interaction continues a paused tool batch from a
  user or browser response.

```text
          [ 1. Start / Resume Request ]
                          |
                          v
          [ 2. Save Request & Commit ] <---------------+
                          |                            |
           Submit Request |                            | Next Round
                          v                            |
          [ 3. Asynchronous IAP Processing ]           |
                          |                            |
             HTTP callback to webhook                  |
                          v                            |
          [ 4. Process Result & Run Tools ] -----------+
                          |
                          +----> [ 5. Final Answer / Pause ]
                          |
                          +----> [ 6. Child Session (Subagent) ]
                                                 |
                                      (Same loop, steps 2-6)
                                                 |
                                      (Result to parent batch)
```

Requests are saved before commit and submitted to IAP afterward, ensuring
their state is visible when the result arrives. IAP delivers model results
through signed HTTP requests to our webhook endpoint. The signature and
request UUID are checked before we restore the saved user and context
and process the response. Tool calls still run synchronously within
that request.

Agents can now delegate work through tools that start or continue child
sessions. Each child has its own conversation history and uses the same
loop, including further delegation. Its result returns to the parent's
pending tool batch, which continues once the required results arrive.

The browser now receives messages, loop state, pending interactions, and
client tools through the bus instead of the response stream. User and
browser responses resume the saved tool batch, with client tools
targeted to the requesting tab.

Existing AI integrations and tests are adapted to the webhook-driven flow.

TASK-ID: 5153883

Co-Authored-By: Andrzej(pian) <pian@odoo.com>

**Description :-**
This PR introduces a front-to-back version control mechanism for the version records (hr.employee / hr.version). When an end-user attempts to modify a version that is protected with validated payslips, the system intercepts the modification in real-time and prompts the user with an interactive confirmation dialog (VersionUpdateDialog).

The user can choose between two operational modes:-
. Create New Version: Closes the current version and creates a new active hr.version record incorporating the modified fields, and relinks the employee.
. Correct Current Version: Bypasses version splitting and applies modifications directly to the active version record (displaying a warning regarding payslip impacts).

**Implementation :-**
The feature is implemented cleanly by inheriting the base hr form view (hr_employee_version_form) and extending HrEmployeeFormController without using global record patching, onRecordChanged() method overridden to intercepts the version updates flow

1. [ Field Modification on the version form view ]
                      │
                     ▼
2. Controller Interception (onRecordChanged)
                │  • check the version status via RPC: action_check_version_status
                │  • Halts execution flow with an asynchronous Promise wrapper
                │
                ▼
3. Interactive Protection Prompt (VersionUpdateDialog)
                │  • Renders responsive options ("Create New Version" vs "Correct Current Version")
                │  • Captures effective start date for new versions
                │
                ▼
4. Promise Resolution & State Caching
                │  • Apply: Resolves selection object { mode, dateStart } -> Cached in this.versionChoice
                │  • Discard / Close: Resolves null -> Triggers record.discard() to revert pending edits
                │
                ▼
5. Intercepted Save Execution (save())
                │  • Mode A ("create_new_version"): RPC calls action_create_version_from_update,
                │    resets old record state, and reloads view model to the new version.
                │  • Mode B ("correct_current_version"): Executes standard ORM write via super.save().
               ▼
6. Apply the changes

task-6482857

Previously, the "Apply HTML to Page" and "Write Custom CSS" tools blinded the agent to actual edit failures by always returning a success string. Additionally, the agent hand-wrote form markup, which frequently resulted in broken forms that were not editable in Odoo's website builder or missed a destination.

This commit introduces comprehensive edit reporting and a dedicated tool to safely handle webforms:

- Edit Reporting: The HTML and CSS tools now return a `client_tool`entry (`website_apply_html`, `website_reload_css`). The builder applies the actions and returns a detailed report (success/errors, dropped elements, post-edit content, duration).
- Edit Webform Tool: Form work is now handled by a dedicated tool rather than raw HTML edits. Specs (actions, fields, visibility, layouts) are validated server-side and applied via the builder's form plugin machinery. Raw form HTML in the standard apply tool is now explicitly rejected.
- JSON Form Context: Webforms are exposed to the agent as JSON under `website_page.forms` instead of raw HTML, replacing the markup with a marker. The tool result returns the updated form in the same JSON shape.
- Advanced Primitives: The webform tool supports multi-step forms, choice display variants, sliders, and computed fields.
- Skill Updates: The agent's instructions are updated to check edit reports, retry failed actions, and steer wizards/live totals towards the new form primitives instead of hand-building them.

task-6251785