**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

Forward-Port-Of: odoo/odoo#219279

Description of the issue/feature this PR addresses:
When a user updates the subject on a template used for a survey, it does not pull the subject from the template. It uses the default subject that is used when computing the subject for a survey email that is sent out. This bug came as a part of [this commit](https://github.com/odoo/odoo/commit/220e0271bf43e914950b8ae0d4a1cca5f3ea6d9c).

I've used an elif condition over here as opposed to calling super which was being done before so that the default of Participate to X survey still becomes the default subject. 

opw-4654411

Steps to reproduce on runbot:
1. Go to mail templates and search for Survey
2. Open the Survey: Invite template
3. Update the subject on this template
4. Open the Surveys app and select any survey
5. Click on Share and then enable send by email
6. The subject here will default to "Participate to {Survey Name}"

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

Forward-Port-Of: odoo/odoo#219122
Forward-Port-Of: odoo/odoo#211153

Issue
-----
Incoming return slips have a "Demo Address and Name" text instead of the correct destination address.
<img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" />

Steps to reproduce
-----
- Create a receipt for a product
- Print its return slip

Cause
-----
By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field.

Note
-----
To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016

With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it.

-----
Ticket:
opw-4660716

Forward-Port-Of: odoo/odoo#219011

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

Forward-Port-Of: odoo/enterprise#91927