The report is missing a root report that is common in reports from other localizations. Withouth it, the states workflow changes from Review, Submit, Pay in 18.4 to just Review in 19.

<img width="594" height="159" alt="image" src="https://github.com/user-attachments/assets/8362e293-0677-45df-bac1-c613ef313a52" />
<img width="571" height="146" alt="image" src="https://github.com/user-attachments/assets/b26a3a7e-c3ca-4512-809f-3db0fc597ba2" />



---
It can also trigger an error after upgrading to 19. To reproduce:
- Install accountant and l10n_ae_reports in 18.4.
- Using an AE company, change a Corporate Tax' state to Submitted.
- Upgrade to 19.
- Navigate to Tax returns.

You will get the error
```
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 926, in _compute_next_state
    next_state_index = state_keys.index(record.state) + 1
 ValueError: 'submitted' is not in list
```

Since the report linked to return type lacks a root report, it got assigned `generic_state_review` as `states_workflow` that only allows for Review.

---
Please note: I'm not an expert in accounting or localization. I saw an upgrade failing on this, looked at the problem and took an educated guess. I don't know if the root report is missing on purpose for some functional reason. If that's the case, let me know and I will try to do something on the ugprade script for these cases.

Version: saas-18.4 (first affected version)

**Issue**
When archiving versions for an employee, Odoo correctly prevents archiving
the last remaining version when done individually.
However, when multiple versions are selected and archived at once from the 
employee history view, all versions are archived without any validation error.
This leads to an invalid state where an employee has no active versions.

**Steps to Reproduce**
1. Create an employee
    - A first version is automatically created.
2. Try to archive this version
    - An access error is raised (correct behavior).
3. Create two additional versions for the same employee.
4. Go to Employee History, select all versions, and click Archive.
5. All versions are archived without any error (unexpected behavior).

**Expected Behavior**
Archiving all versions of an employee should always be blocked, regardless of
whether the action is performed on a single version of multiple version at once.

### Solution
Before archiving, the system now verifies that at least one active version will remain for each employee. 
If an archive action would remove all active versions, it is prevented with a validation error.

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

In discuss, thread / message / composer / call / attachments actions dropdown style all differ visually. This comes from each defining their own template. This becomes hard to fix and improve visual of action to make discuss more intuitive.

This commit defines a generic `mail.DiscussActions` that renders (dropdown) actions. This centralized template allows to put more effort in a nicer look, and is a step towards harmonizing the definition of discuss action registries.

TODO: inline style for chat window quick part + message quick part, thread inline actions use "large" mode

mobile message actions is not yet considered in this PR.

This commit also makes miscellaneous style improvements:
- chat bubble message preview uses bubble color of last message
- fixes minor discuss sidebar option / actions alignment
- chat window thread panel back button is chevron rather than arrow
- chat bubble in mobile do not move on click
- chat window header "more action" has better visual feedback
- message action dropdown orientation takes message alignment in conversation
- hashtag / globe channel icon have reduced opacity to match other discuss status icon
- image actions button is "..." rather than chevron to be consistent with other discuss "options" buttons' icon.
- rounded panels and button

Before this commit, chat hub in website was confusing for internal users:

- correspondent + avatar for live chat conversations was wrongly computed (e.g. self-operator was considered a visitor)
- many thread and message actions are not available compared to web client.

This commit fixes both issues as follow:
- many features in web client chat hub are now available for internal users in website chat hub.
- computation of correspondent and livechat actors is correct for operators in website chat hub.

Making the website chat hub almost feature full-fledged is helpful to solve the duplicated chat hub in the website builder, so that using the website chat hub is barely a regression over the web client chat hub.


----

Before this commit, website builder page was showing 2 chat hubs at once:
- chat hub from the web client
- chat hub from the live chat on website

The website builder is in web client so makes sense to enable chat windows from web client. Some feature are specific to backend and need to be shown while editing the website. The website builder also previews how the website look. Therefore it makes sense to show live chat hub because it's part of the actual website page being previewed.

The problem with showing the 2 chat hubs is that chats are duplicated due to being shown in both hubs. The chats are intended to be seen from the website so the underlying problem is showing both chat hubs at once.

This commit fixes the issue as follow in website builder:
- when not editing the website, show the live chat hub and hide the web client chat hub
- when editing the website, show the web client chat hub and hide the live chat hub.

This works because web client chat features at desired when actually editing the website. Viewing live chat hub when not editing the website works because this is the actual showing of website with the live chat hub. There's also no feature on website editor that affects the website live chat hub.

Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited.

This happens because some store data are exclusively feed from return data of RPC whereas some store data are feed from bus notifications. Ordering of data are essentially sound among RPC returns and bus notifications, but not between the 2 groups. Therefore RPC return or bus notifications can come before or after the other one, and the ordering may be wrong and result in wrong store data.

In practice bus notifications usually before return of RPCs. Most of discuss code is robust against this ordering, even though there's likely many potential of race conditions that may happen and are genuine bugs. When bus notifications come after returned RPCs, however, problems are more apparent. This may happen when the bus notification queue is slow, but also in tests this is likely to happen because RPCs are simulated with single micro-tick whereas handling of bus notification is usually more than 1 micro-tick.

The test "Can edit message comment in chatter" is showing this problem: it's a relatively long test that interacts a lot with message edition, which has the message content being obtained from both bus notifications and RPC returns. When the CPU load is high, test takes much more time to run, e.g. 400ms becomes 2500ms. This CPU load affects barely RPC returns but bus notifications are heavily throttled and therefore causes bus notifications to come much later than expected. Test edits message twice with different content and then once without any change. The high CPU load can make test fail after 3rd edit step because the content of message is the 1st edited content instead of the last. The last edition is coming later in the bus notification, but due to timing constraints of 3 seconds assertion can lead to timeout of test because the message is not showing the most recent edited content.

Roughly:
1. message is "original message"
2. message is edited to "edited message"
3. message shows "edited message (edited)"
4. message is edited to "edited again"
5. message shows "edited again (edited)"
6. message editing is started => message content in composer is "edited message" instead of "edited again", so crash after 3 seconds

Step 6 fails because message content between 5 and 6 is changed to "edited message" from the bus notification. All previous steps had the message edited relatively quickly (500ms each) by returned RPC. The bus notifications are throttled to about 3 seconds, thus the "edited message" bus notification arrived very late when starting edition in step 5. The composer content is wrong and the contains wait for at least 3 seconds, but due to heavy throttle of bus notifications from CPU load, the test fails.

This commit fixes the issue by introducing a `busRpc()` function on bus_service and have message edition flow use this busRpc() rather than `rpc()`. This `busRpc()` function is a special flavour of `rpc()` that awaits until the RPC and related notifications have been received. `busRPC()` works by forging a UUID bus_rpc_uuid that the RPC sends back at end of RPC. The `busRPC()` function waits until this notification is received.

This commit ensures ordering of store data received from server is good, because RPC properly awaits bus notification. Store data of RPC return makes sense after these bus notifications, but ideally it should also be sent to bus notification and business code should ignore returned data from RPC, so that ordering of store data is always good even with interleaving if discuss actions.

This also solves the race condition in the test "Can edit message comment in chatter", because each assertion of message content ensures we are in the window of data feed by related bus notifications. When a message is being edited the composer is not affected by new message content from store data of bus notifications, but the save of the message edition should necessarily have to await related bus notifications, ensuring no previous bus notifications can be feed after this store data state.

Fixes runbot 227618

### Issue:
An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries
Some Italian banks reject SDD files containing this node

### Cause:
https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries
The original fix was intended for Nordea (Sweden) only, which requires this node explicitly
The assumption that other countries would accept it was incorrect

### Steps to reproduce:
- Install `account_sepa_direct_debit` and `l10n_it`
- Switch to the IT company
- In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042`
- Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount)
- Create and validate a Batch Payment with that payment
- Open the generated PAIN008 XML

Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present

opw-6530996

Forward-Port-Of: odoo/enterprise#130304

TL;DR
- we lose the measures from arch after a reload, if removed from activeMeasures

Step to reproduce:
- install pos, create few orders
- go to reporting> orders> switch to pivot view
- click the `Measures` dropdown,  `Order` is already selected
- untick it, then apply some filter so that view reloads (ex order date)
- reopen `Measures` dropdown, notice `Order` is missing form measures

Cause:
- view `view_report_pos_order_pivot` has `<field name="order_id" type="measure"/>`  in its pivot view
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/point_of_sale/views/pos_order_report_view.xml#L10
- `order_id` is M2O field
- Measure is compute from present `activeMeasure` and fields of type `["integer", "float", "monetary"]`
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/utils.js#L89-L120

- when the view is first loaded, `activeMeasure` all the fields with `type="measure"` which is directly passed to pivot's model as a metadata
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_arch_parser.js#L59-L60

https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_view.js#L41
- when we toggled the `order_id` from measure and reloaded, `order_id` is popped from  `activeMeasure` and as it's field type is `many2one` it is not considered for `measures` in `computeReportMeasures`

Fix:
- maintain the measures from arch separately and feed it to `computeReportMeasures`

opw-6416196

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

Forward-Port-Of: odoo/odoo#285686
Forward-Port-Of: odoo/odoo#278850