Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if this is in response to `stop`-ing the page, or a pre-existing navigation directive interfereing with the stop-ing of the browser. I tried reproducing locally under the assumption that the `Page.stopLoading` might be the cause but got nowhere[^1].

This issue seems extremely infrequent, and in most cases is but a minor annoyance, an error appears on the corresponding build, and that's it.

However if the error occurs during `ChromeBrowser.stop` then the browser is not terminated, which on runbot prevents the docker image from shutting down properly, and leaves zombie builds.

Therefore make `ChromeBrowser.stop` more resilient to errors in the initial section so that we do terminate the browser even if the "graceful CDTP shutdown" fails. While at it, add a fallback to kill the browser if it does not terminate gracefully.

https://runbot.odoo.com/odoo/error/233442

[^1]: and the error only happening in 18.0 and later when `Page.stopLoading` was present long before that makes it likely the proximal cause is in the code being run, especially as all the errors sampled from the builds list are related to pos and the failure are immediately preceded by ongoing HTTP requests

## Versions
17.0+

## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.

## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
  - Create a new invoice in "CNY" currency for any customer with at least 1 product;
  - Confirm and click on the preview button:
    - Click on the "Pay now" button then "Pay" button of the wizard.

## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.


opw-5071893

**Steps to reproduce:**
- Install Accounting and Contacts

- Go to "Settings / Translations / Languages"
- Activate another language (e.g. French)

- Create a contact with an email and French as language
- Create another contact with an email and English as language

- Go to "Settings / Technical / Email / Email Templates"
- Edit "Invoice: Sending" email template
- In "Email Configuration" tab, add the email of the English contact in "Cc" field

- Create an invoice for the French contact
- Confirm the invoice
- Send the invoice

**Issue:**
The invoice is sent by email to the customer and to the email configured as CC in the template.
Both emails are in French, but some terms in the email header for the CC contact are in his configured language.
For example, instead of "Voir Facture", it's written "View Facture". And instead of "$10 dû le 01/01/2025", it's written "$10 due 01/01/2025".

**Cause:**
The content of the email and the model description is translated in the language of the customer of the invoice.
However, when grouping the recipients of the email, they are grouped by their language, leading to a mix of languages for some recipients.

**Solution:**
In the method grouping the recipients by lang, there is a parameter named "force_email_lang" that is the lang used for the content of the email, but it is only used as a fallback when a recipient doesn't have a lang configured.
From the name of the parameter (i.e. force_email_lang), it should be use in priority if set.

opw-4904029




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

Steps to Reproduce:
- Open a Repair Order form view in Odoo 17 or 18.
- Navigate to the Parts tab.
- In the list view of parts, click the Smart Button on any part line.
- A pop-up form view opens showing detailed operations.
- Click the “Pick From” field value, but don't change its value.
- Click the Save button in the pop-up.
- Observe the browser console for the error: TypeError: Cannot read properties of null (reading 'querySelector') at ListRenderer.focusCell

Traceback:
```py
TypeError: Cannot read properties of null (reading 'querySelector')
    at ListRenderer.focusCell (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9519:80)
    at ListRenderer.<anonymous> (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9477:272)
```
Root Cause:
- Asynchronous patching in OWL (onPatched with await Promise.resolve()) continues execution after the next tick, even if the component is destroyed.
- When the component is destroyed, OWL sets status(this) = 3 (DESTROYED).
- focusCell() accesses DOM using querySelector, which fails if the component is destroyed.
- The code did not check the component status before calling focusCell().

Fix:
- Added `if (status(this) === destroyed) return;` to stop focusCell() execution on destroyed components.
- Ensured async patching is handled safely with await Promise.resolve().
- Added `onWillDestroy` to clean up dialog callbacks, preventing memory leaks.

OPW - [5154694](https://www.odoo.com/odoo/project/70/tasks/5154694)
[PAD](https://pad.odoo.com/p/issue_5154694_shku)
Localhost issue reproduction [steps](https://drive.google.com/file/d/1wkglUosOveUseU0mBePZcQAFB_ZWr3uM/view)

17:https://github.com/odoo/odoo/blob/f9726cfe93e8850a38d9de06acfa5d78473b50b0/addons/web/static/src/views/list/list_renderer.js#L223
18:https://github.com/odoo/odoo/blob/1cac54db8634267a780b4011291f1e8a80ac5f5b/addons/web/static/src/views/list/list_renderer.js#L213

Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:

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