*: test_mail_enterprise

Before this commit, on CRM leads kanban cards, there was a phone and plus/minus icon button that allowed users to easily add/remove call activities due or overdue for today for that lead. While this was nice, it encumbered the card and will not fit nicely in new designs anymore.

Instead, this is replaced by an action button that appears when you select records, in kanban or lists. This is also added for simple contact records (all models using the `voip.queue.mixin` at the moment).

Side-effects:
- You don't have to possibility to delete calls from the queue easily anymore (you have to do it one-by-one). Functionally it might be better to have the opportunity to cancel and log the reason anyway.
- If you try to add a call activity while there is already one, it does nothing for the related call.
- If you try to add a call activity but there is no phone number, it will prevent you to add the activity on all selected calls (with a message explaining what record prevented the action).

task-6377768

## Summary

This PR adds a unique index on `ai.composer` to prevent duplicate **Default Prompts** for the same **AI Agent**, **interface key**, and **focused model**.

Previously, multiple records could exist for the same `(ai_agent_id, interface_key, focused_model_id)` combination, leading to inconsistent data and runtime issues such as singleton errors when the AI composer expected a single matching record.

The unique index uses PostgreSQL's `NULLS NOT DISTINCT`, ensuring that `NULL` values in `focused_model_id` are treated as equal and duplicate generic Default Prompts are also prevented.

## Changes

- Add a unique index on the `(ai_agent_id, interface_key, focused_model_id)` triplet.
- Use `NULLS NOT DISTINCT` to enforce uniqueness even when `focused_model_id` is `NULL`.
- Add test cases to verify the unique constraint behavior.

## Upgrade

Duplicate `ai.composer` records are removed before applying the unique index.

Upgrade PR: https://github.com/odoo/upgrade/pull/10819

---

opw-6323764

Forward-Port-Of: odoo/enterprise#121609

Description
===========

When batch payroll journal items are enabled, all payslips for the same journal and accounting period contribute to one accounting move.

For every salary line, `_prepare_slip_lines()` searched the complete list of previously prepared move lines for both the debit and credit entries. It also created a new `line_ids + new_lines` list for every search. As the move grew, accounting validation time grew quadratically.

This commit keeps a shared index while preparing the move. It is keyed by the stable aggregation fields: line name, account, and analytic distribution.

Only lines in the matching bucket must then be checked for compatible debit or credit signs and tax tags.

Benchmark
=========

The blueprint creates 500 validated payslips and 10,000 payslip lines. All lines are accumulated into one accounting move.

On a fresh database with `hr_payroll_account` and `populate` installed, populate the data with:
```sh
    ./odoo-bin populate\
        -d <database> \
        -b hr_payroll_account.benchmark_payroll_account_move_creation \
        --seed 42
        -j 4
```

Run the benchmark with from the [gist](https://gist.github.com/pivi-odoo/3a5a21bb42f82d5ae10646d15986013b):
```sh
    ./odoo-bin shell \
        -d <database> \
        < benchmark_prepare_slip_lines.py
```
The benchmark measures `_get_account_move_vals()` with a cleared ORM cache before every sample.

| Payslips | Input lines | Move lines |  Before |  After | Speedup | 
|---------:|------------:|-----------:|--------:|-------:|--------:|
|       20 |         415 |        398 |  0.634s | 0.093s |    6.8x |
|       50 |        1004 |        986 |  3.040s | 0.178s |   17.1x |
|      100 |        1992 |       1974 | 11.865s | 0.344s |   34.5x |
|      200 |        3942 |       3884 |       - | 0.648s |       - |

Reference
=========
task-6429789

This contains a bunch of UX and data cleanups across the Brazilian fiscal localization:

- Selection labels for activity sector, tax regime and SPED type now have human-readable text instead of the raw API codes, SPED type is prefixed with its official code,
- NCM codes get a new is_service flag distinguishing goods (NCM) from services (LC116), with search filters, a "NCM / LC Codes" menu and a product code field filtered on the product type,
- NBS codes can now be archived,
- Clean up the settings: rename "Simplified Regime ICMS Rate" to "ICMS Simplified Credit Rate" with a Brazil-specific tooltip, drop the duplicate CBS/IBS Normal toggle (kept on the company contact) and align the CNAE field,
- Show the operation type Technical Name on its form,
- Reorder the contact Fiscal Information fields and rename the product "Transport Cost Type" to "Additional Cost Type",
- Open the partner form when a single contact is missing Avatax fields, and the Brazil-specific list for several,
- Validate the correction letter reason length in Odoo so a short reason no longer shows a raw XML schema error from Avalara,

task-6327269

Enterprise counterpart of odoo/odoo#281228 — same scope, same criterion.

The Owl 3 migration changed contracts (refs became `signal.ref()`, `AccountReportController.options` became a signal) and left some consumers reading the old shape. This PR collects **our own oversights**: call sites that were already on master when we changed the contract under them. Forward-ports that landed *after* a contract change are handled separately, in odoo/enterprise#127207, so the two can be reviewed and backported independently.

### Fixed

- [x] `l10n_uk_reports` — `patch_button_report.js` read `this.options.available_tax_units` on what Reactivalypse had turned into a signal three weeks after this code landed. Confirming "Select Tax Unit" when filing a VAT return from a company that belongs to a tax unit throws on `[0]`, and `saveSessionOptions` was handed the signal itself rather than the options.

### Coverage

Enterprise has not had the systematic sweep that odoo/odoo#281228 got. `rootRef.el` is clean, and the ref-contract check over forward-ports came back clean apart from #127207, but the equivalent of that PR's `signal.ref()`-declaration audit has not been run here, and reads of properties a refactoring turned into signals — the `options` shape above — have no syntactic tell and are not greppable at all. Expect more sites to land in this PR.

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126849
Forward-Port-Of: odoo/enterprise#125798

The keypad had 3 calling usecases:
- Hitting "Enter" in the number/contact input
- Clicking a call/phone button
- Longpress on the voicemail button

This commit moves the responsibility of those actions to the parent component. Indeed, the keypad is used in 3 places:

- Dialer: the main one. In the end the only wants who wants to initiate actual calls. It now passes "how to call" to the keypad, which does it for "Enter" / click a call button. It also passes "how to voicemail" which becomes the condition to display the voicemail button in the first place (instead of the keypad hardcoding "am I in the dialer?").

- Transfer during a call: same as the dialer, it passes "how to transfer" which the keypad does at the same places as "how to call".

- DTMF keypad during a call: that one definitely don't need to know how call / transfer / voicemail so it is not given anything about that.

Funny enough: the third case was actually buggy. If during a call you opened the DTMF keypad, hit numbers then hit "Enter"... you would start a new call with the DTMF numbers. This is fixed here but that part will get a dedicated minimal fix in stable, with a test, forwarding up to master later on.

Related to task-6365445
Related to task-6455637