**Steps to reproduce**:
- install the `accounting` module.
- Go to `Settings -> Technical -> Actions -> Reports -> Invoice or Invoice without payment`
- Change the printed report name
- Try to print the report via the print menu (gear icon -> print) -> The report is shown with the new updated name.
- Try sending the invoice the regular way -> the attached invoice has the default name, Odoo ignores the changes.

**Observation**:
When printing the invoice manually, the file name correctly reflects the custom name configured in the report action. However, when sending the invoice by email, the attachment file name does not match the updated name and remains hardcoded.

**Issue**:
The email attachment file name is hardcoded in the mail sending logic. in the method:
```python
def _get_invoice_report_filename(self, extension='pdf'):
        self.ensure_one()
        return f'{self.name.replace('/', '_')}.{extension}'
```
It does not dynamically fetch the updated report name from the configured report action.

**Solution**:
When a custom report template is configured on the customer on field `(invoice_template_pdf_report_id)`, the system now dynamically uses the corresponding name from the report action for the email attachment.

opw-4923035

### Steps to reproduce:

- Go to the To-Do app and type something in the editor.
- Select the typed text.
- Click on the Font Size Input and choose a value from the dropdown (e.g.,80).
- Try typing again in the editable area.
- Selection is still visible, the focus is no longer in the editable area.

### Description of the issue/feature this PR addresses:

- `focusEditable()` skipped restoring focus if the selection was inside the editor, even when the editor itself wasn’t focused.
- When the font size input (inside an iframe) is focused, editable loses focus.
- Selecting a value from the dropdown blurs the iframe input, but focus is not returned to the editable area.
- As a result, the selection is still visible but the user cannot type.

### Desired behavior after PR is merged:

- Does nothing if the editor or its descendants have focus.
- Focuses the editor if needed.
- Restores selection only when it's outside the editor.
- When the iframe input is blurred, focus is returned to the editable area.

task-4932364

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Steps to reproduce**:
1. Install the `account` module.
2. Create a Invoice using this any product.
3. add long descripition (approx. 40-45 lines).
4. Print the PDF of Invoice (via gear icon).

**Observation**:
The long product description overlaps with the table header when the table spans multiple pages in the generated PDF.

**Issue**:
wkhtmltopdf does not handle multi-page table headers properly by default. causing header/content overlap when the table breaks across pages.

**Solution**:
Apply a known wkhtmltopdf workaround by explicitly setting:
  `<thead style='display: table-row-group;'>`
This ensures headers will not repeat same as this. [#53909](https://github.com/odoo/odoo/pull/53909)

before:
<img width="818" height="231" alt="image" src="https://github.com/user-attachments/assets/8bcc6ced-5911-4abd-b91e-97ffa8fb735e" />

after:
<img width="821" height="253" alt="image" src="https://github.com/user-attachments/assets/2ccc6995-c239-4beb-8f68-53d548b7f2f2" />

opw-4982735

Forward-Port-Of: odoo/odoo#221681

### Steps to reproduce:

- Type some text and apply a large font-size.
- Select the text and apply the button style.
- Notice that the font-size is not reflected on the button.

### Description of the issue/feature this PR addresses:

- The `<a class=btn>` element was placed inside a font-size `<span>`.
- However, the `.btn` class defined its own font-size, causing the original styling to be overridden.

### Desired behavior after PR is merged:

- Improved the splitAroundUntil utility to correctly handle cases where the target node has no previous or next sibling. In such edge cases, the function now recursively splits up the inline ancestry until the specified limitAncestor, ensuring that the target node is fully isolated.
- The font-size `<span>` is moved inside `<a>` tag when applying a button style.
- This ensures the original font-size is preserved and correctly displayed.

task-4731416

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Description of the issue/feature this PR addresses**:
It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the jurisdictions they apply to.

**Steps to reproduce**:
1) Go to runbot odoo 18 instance, install l10n_ar module, take position on Argentinean company and activate "Spanish (Latin America)" language.
2) Go to "Accounting / Configuration / Accounting / Taxes", filter by "Sales" Tax Type (type_tax_use) and see that Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe don`t have the complete description. It is needed to show the complete description.

<img width="1825" height="307" alt="image" src="https://github.com/user-attachments/assets/f664e5ec-a4b5-4a8f-bbab-9ba3d824bd2b" />

**Current behavior before PR**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes don`t have the complete description.

**Desired behavior after PR is merged**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes have the complete description.
<img width="1828" height="425" alt="image" src="https://github.com/user-attachments/assets/dc8ee6dd-23c3-40c1-a973-943971e3cb78" />

**Task Adhoc side**: 53028
**Task latam side**: 1356

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.

problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.

Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.

Runbot-145458