### [IMP] databases: remove xmlrpc fallback for odoo.com

Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version.

In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`.

In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code.

The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page.

### [FIX] databases: disable the KPI-selection wizard

With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field.
Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view.

The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2).

Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314)

### [FIX] databases: handle fetch errors better

With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user.

### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously

Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action.

With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action.

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

Forward-Port-Of: odoo/enterprise#105648

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559

Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474

Currently, On renaming or updating roles in the sign template doesn't get saved due
to which drag-drop 'Signature Item' is reseted back to 'Signer 1'.

**Steps to reproduce:**
1) Install sign app.
2) Open the Sign app and select a template.
3) Case A (Direct Rename): In the sidebar, rename a role from
   'Signer 1' to 'Signer 1-Test'.
4) Case B (Edit Button): Click the '3-dots' button on the role and click `edit`,
   change the name to 'Signer 1-Test', and save.
5) Drag and drop 'Signature Item' to template.

**Observed Behaviour:**
- The Role is not updated as `Signer 1-Test` and reset back to `Signer 1`

**Expected Behaviour:**
- The Role should be updated as `Signer 1-Test`.

## **Root Cause:**
### **Case A:** 
The `updateSignerNames` method(see[1]) checks `if (signer.name.includes(str))`
where `str` is `Signer` This condition evaluates to true for any custom name
containing that substring, causing the code to overwrite the user's custom input
with the default generated name string.

### **Case B:**
1) The method `updateRoleNameAndAvatar` see([2])  updated the local state `this.state.roleName`
   but failed to trigger the `onChangeRoleName` prop. As a result, the
   parent component (`SignTemplateSidebar`) remained unaware of the change
   and overwrote the name with its stale value during the next update cycle
   (triggered by the drag-and-drop action).

2) **when `sign_emsigner` module is installed:**
   The module patches `openSignRoleRecord` to manually set `this.state.roleName = data.name`
   before the role update process completes. However, `onChangeRoleName` relies
   on the condition `name !== this.state.roleName` to decide whether to notify
   the parent component (via `this.props.updateRoleName`). Since the state is
   already updated manually, this check fails (returns false), the parent is
   never notified, and the database is not updated. When `sign_emsigner` subsequently
   triggers a re-render (via `displayAddDocumentButton`), the parent passes down
   the old, state name, reverting the user's changes.

### **Fix:**
1) Remove all `updateSignerNames` logic since it is difficult to distinguish between a
   default-generated name and a user-customized name.

2) Update `updateRoleNameAndAvatar` to call `this.onChangeRoleName` with
   the new name, ensuring the parent component's state is synchronized.

[1]- https://github.com/odoo/enterprise/blob/382dd07b8ef93e9315963825e69066155a534ba0/sign/static/src/backend_components/sign_template/sign_template_sidebar.js#L92-L102

[2]- https://github.com/odoo/enterprise/blob/afc32de0a2757d8f241886ce27736fb7c07ab8c7/sign/static/src/backend_components/sign_template/sign_template_sidebar_role_items.js#L121-L122

**opw-5389063**

Currently when a user creates a new template from a marketing campaign, they can’t edit the `email_from` and `reply_to` fields, even though these should be editable in the template.

**Steps to replicate:**
* Install `marketing_automation`
* marketing automation > Create a New campaign > Add a new activity
* Mail template > Create a new template > Settings

**Observed Behavior:**
The fields `Send From` and `Reply To` are not editable which should be editable.

**Root cause:**
* After commit [1], the form view `mailing_mailing_view_form_marketing_activity` [2] was removed, so `email_from` and `reply_to` now come from the view [3]. Because that view inherits the `mass-mailing form`, its `readonly` rules apply (see [4]), and with `default_state` set to “done” (see [5]), those fields become `readonly` when creating a new mail template.

**Solution:**
Modify the readonly conditions to match how they were handled in earlier versions (see [6]).


**Before:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/72006a7f-1ee5-40dd-8899-4eb932f503b7" />
**After:**
<img width="1182" height="591" alt="image" src="https://github.com/user-attachments/assets/d5d6bdf2-1fb6-4e7b-9527-412c44986050" />

[1]:
https://github.com/odoo/enterprise/commit/a469218b32943ddaa83271565e73311cfd188f84 
[2]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L75-L143 
[3]:
https://github.com/odoo/enterprise/blob/307b23b0f6b377c43463a04aabf0b2f03c256072/marketing_automation/views/mailing_mailing_views.xml#L107 
[4]:
https://github.com/odoo/odoo/blob/9e04aadb83d482d05fc2fa66fa3c3bebb6ac1528/addons/mass_mailing/views/mailing_mailing_views.xml#L328-L337 
[5]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/marketing_activity_views.xml#L23 
[6]:
https://github.com/odoo/enterprise/blob/97f6f87cca3939e48d3488672aba0df68acd8f9b/marketing_automation/views/mailing_mailing_views.xml#L96

opw-5401422,5449345,5369836

To reproduce:
=============
1. Create an new Overtime Ruleset using these options:
- The rule is based on: Timing
- With tolerance in favor of the employer of: 00:00
- If the employer works: Outside of a specific schedule
- Schedule: 40/hour work week
- Pay extra hours: with rate of 100%
- Work entry type to use: Overtime Hours
- Give back as time off
2. Create an employee or edit an existing employee to use the overtime ruleset in the settings of the form view of the employee.
3. Navigate to attendance and create a new entry for that employee.
4. Make clock in time and clock out time run through a Friday. For example:
Clock in: 12/22/2025 12:00:00 AM
Clock out: 12/26/2025 6:30:00 AM
5. Then edit the entry to run through the Saturday or Sunday. For example:
Clock out: 12/27/2025 6:30:00 AM
6. Navigate to Work Entries and navigate to the month or week that that entry was made at.
7. There should be a traceback error for more than one overtime line related to that specific entry.

Problem:
========
When allocating multiple overtime lines to consecutive time periods, the
`_set_real_overtime_intervals` method was merging them into single intervals
with recordsets of overtime lines (e.g., hr.attendance.overtime.line(102, 106, 103, 104))
instead of keeping each overtime line in its own separate interval. This happened
because the allocation logic incorrectly calculated the position within intervals
and subtracted the wrong duration from remaining overtime, causing the `|=` merge
operator to combine adjacent allocations into recordsets.

Solution:
=========
Refactored the overtime allocation loop to maintain singletons

opw-[5468598](https://www.odoo.com/web#id=5468598&view_type=form&model=project.task)

After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left
join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records.

In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the
the relevant dates not all dates between the min starting date and max ending date
of all slots.

Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c

The testing cardinality of the tables:
`planning.slot` 7178 rows
`hr.employee` 332 rows
`resource.resource` 332 rows
`resource_calendar_leaves` 4061 rows
`account_analytic_line` 267376 rows
`generate_series()` will produce 206417 rows

| Before                                  | After |
|-----------------------------------------|-------|
| Query keep being active with no results | ~2s   |

opw-5089052

Forward-Port-Of: odoo/enterprise#105696
Forward-Port-Of: odoo/enterprise#102283