As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

Forward-Port-Of: odoo/enterprise#126764

As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

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