Before this commit, when logging in as Demo user with a direct chat, logging out + logging in with Mitchell Admin would crash with the following error:

```
TypeError: can't access property "imStatusUI", this.channel.correspondent is undefined
```

This happens because this attempts to restore the direct chat in chat window. Normally this shouldn't happen thanks to being unable to fetch inaccessible channels, however Mitchell Admin is the admin of DB thus can fetch the channel data. The crash comes from computation of `correspondent` that is `undefined` because it can't determine a correspondent from the Point of view of Mitchell Admin, and the template isn't defensive against missing a `correspondent` in a direct chat.

One solution could have been to support opening of direct chat, but this implies fixing a lot of complex issues, such as:

- Mitchell Admin can't use composer because this attempts to add a member but there's a contraint for direct chat to have at most 2 members
- This direct chat looks like a group chat without a name, we can guess this is a direct chat only because of broken avatar and the start message in message list stating this is a direct chat
- Several other actions show weird behavior, like "Invite People" ignoring people in the chat

This commit fixes the issue by ignoring the restore of chat in chat hub for direct chats that current user is not a member.

Forward-Port-Of: odoo/odoo#277199

Translatable rows that are identified by a stable key rather than by
their text (e.g. selection option labels in ir.model.fields.selection,
and other module-reflected metadata written through upsert_en()) can
have their English source text changed by a module upgrade while
keeping the same key. For example product.template's selection value
'consu' went from meaning "Consumable" to meaning "Goods" between 17.0
and 18.0, without the stored value itself changing.

In that situation, upsert_en() always refreshes the 'en_US' entry from
the current code, so English is never wrong. But every other language
keeps whatever value it had, since upsert_en() blindly merges the new
'en_US' entry into the existing jsonb without checking whether the
previous 'en_US' value actually changed. When the module's .po file is
later reloaded, TranslationImporter.save() finds a non-empty value
already there for each language and, by design, does not overwrite it
unless explicitly asked to (`overwrite`) on a record that isn't
`noupdate`. That protection is correct when the English text hasn't
changed (it keeps manual translation customizations across upgrades),
but here it ends up protecting a translation of a source string that
no longer exists.

As a result, a value whose meaning changes across versions keeps
showing its old label in every language except English, forever,
unless someone forces a translation overwrite.

Fix this in upsert_en() itself: when the incoming 'en_US' value
differs from the one currently stored, drop every other language
already stored for that row instead of merging into it. Those
translations were made for a source string that no longer exists, so
there is nothing worth protecting. Once dropped, they are simply
missing from the jsonb, so TranslationImporter.save() naturally lets
the freshly (re)loaded translations in on its next run, without needing
to know anything about source drift, and `overwrite`/`noupdate` keep
their exact original meaning for every other case.

Task-6333080


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

Forward-Port-Of: odoo/odoo#277491
Forward-Port-Of: odoo/odoo#275080

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order.
3. Close the session.

With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed".

Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too.

Benchmark
---------
These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database:
- before: the close did not finish after more than 10 minutes.
- after: the close takes around 75 seconds.

opw-6242303

Forward-Port-Of: odoo/odoo#274258
Forward-Port-Of: odoo/odoo#269306

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2b42707d52 [REL] 19.3.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d7d612ef1c [FIX] scorecardPanel: mismatch baseline/keyValue [Task: 6380393](https://www.odoo.com/odoo/2328/tasks/6380393)
https://github.com/odoo/o-spreadsheet/commit/67399059e8 [FIX] TableComputedStylePlugin: skip table style for invalid pivot [Task: 6306263](https://www.odoo.com/odoo/2328/tasks/6306263)
https://github.com/odoo/o-spreadsheet/commit/cb96765814 [FIX] squisher: adapted ranges that become cells [Task: 6390727](https://www.odoo.com/odoo/2328/tasks/6390727)
https://github.com/odoo/o-spreadsheet/commit/1e513b5a3e [FIX] index: export `positionMap` [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)
https://github.com/odoo/o-spreadsheet/commit/3bcd6758a2 [FIX] Pivots: cache `getPivotIdFromPosition` for performance [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/fba73fe75b [REL] 19.2.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0266f73f3b [FIX] scorecardPanel: mismatch baseline/keyValue [Task: 6380393](https://www.odoo.com/odoo/2328/tasks/6380393)
https://github.com/odoo/o-spreadsheet/commit/5bb486c814 [FIX] TableComputedStylePlugin: skip table style for invalid pivot [Task: 6306263](https://www.odoo.com/odoo/2328/tasks/6306263)
https://github.com/odoo/o-spreadsheet/commit/ecef954c0e [FIX] squisher: adapted ranges that become cells [Task: 6390727](https://www.odoo.com/odoo/2328/tasks/6390727)
https://github.com/odoo/o-spreadsheet/commit/43bc2d9e1d [FIX] index: export `positionMap` [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)
https://github.com/odoo/o-spreadsheet/commit/1584d3c4b1 [FIX] Pivots: cache `getPivotIdFromPosition` for performance [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When sending an email to an invoice mail alias without valid
attachment, a custom bounce mail is sent to inform the customer
that it was bounced because of a missing attachment.

Currently, the bounce email from will default to the bounce alias
of the main company of the DB.

In a multi company setup, where each company might have their own
mail alias domain, this can be confusing for the receiving party
that didn't send the original email to the main company's alias domain.

## Proposed solution:
We call `_routing_create_bounce_email` with the right
company in the context, since the journal company
is already detected.
Additionally, in the context of the accounting code
calling the bounce private method, we pass an explicit value  for `reply_to`

## How to reproduce it:
1) Set up DB with two companies (companyA and companyB). Install account.
2) Set up two mail alias domains (companya.com and companyb.com)
3) Send an email to the invoice alias of companyB (e.g. invoices@companyb.com).
-> bounce email will have FROM as "notifications@companya.com" (the notifications alias
of companyA)

Example headers before:
```
Reply-To: "YourCompany" <catchall@companya.com>
To: customer@example.com
Date: Thu, 02 Jul 2026 11:18:49 -0000
Return-Path: bounce@companya.com
From: "MAILER-DAEMON" <bounce@companya.com>
```
After fix:
```
Reply-To: info@companyb.com
To: customer@example.com
Date: Thu, 02 Jul 2026 11:16:19 -0000
Return-Path: bounce@companyb.com
From: "MAILER-DAEMON" <notifications@companyb.com>
```

opw-6342778

Forward-Port-Of: odoo/odoo#273671

When sending an email to an invoice mail alias without valid
attachment, a custom bounce mail is sent to inform the customer
that it was bounced because of a missing attachment.

Currently, the bounce email from will default to the bounce alias
of the main company of the DB.

In a multi company setup, where each company might have their own
mail alias domain, this can be confusing for the receiving party
that didn't send the original email to the main company's alias domain.

## Proposed solution:
We call `_routing_create_bounce_email` with the right
company in the context, since the journal company
is already detected.
Additionally, in the context of the accounting code
calling the bounce private method, we pass an explicit value  for `reply_to`

## How to reproduce it:
1) Set up DB with two companies (companyA and companyB). Install account.
2) Set up two mail alias domains (companya.com and companyb.com)
3) Send an email to the invoice alias of companyB (e.g. invoices@companyb.com).
-> bounce email will have FROM as "notifications@companya.com" (the notifications alias
of companyA)

Example headers before:
```
Reply-To: "YourCompany" <catchall@companya.com>
To: customer@example.com
Date: Thu, 02 Jul 2026 11:18:49 -0000
Return-Path: bounce@companya.com
From: "MAILER-DAEMON" <bounce@companya.com>
```
After fix:
```
Reply-To: info@companyb.com
To: customer@example.com
Date: Thu, 02 Jul 2026 11:16:19 -0000
Return-Path: bounce@companyb.com
From: "MAILER-DAEMON" <notifications@companyb.com>
```

opw-6342778

Forward-Port-Of: odoo/odoo#273671