### Commit 1: [FIX] account_peppol: Remove useless div
The div is replaced few lines below, so no need to make it
visible/invisible.

task-no

### Commit 2: [FIX] account_edi_ubl_cii: add belgian EAS translation
task-no

### Commit 3: [FIX] account_edi_ubl_cii: fix typo in EAS
task-no

### Commit 4: [FIX] account_peppol: clean calls to proxy
Before this commit, when calling our Peppol proxy, here is what the call
graph would look like (prefixed by the module the method belongs to):
`account_peppol._call_peppol_proxy`
-> `account_peppol._make_request`
--> `account_peppol._call_peppol_proxy`
---> `account_edi_proxy_client._make_request`

We simplify this to:
`account_peppol._call_peppol_proxy`
-> `account_edi_proxy_client._make_request`

task-no

### Commit 5: [FIX] account_peppol: fix reopening of Print & Send wizard
With previous commit [1], we broke the flow when registering to Peppol
coming from the Print & Send wizard. The Print & Send wizard was not
reopening after successful registration.

task-no

Before this commit, emoji navbar simply had `.overflow-auto`. The size of emoji category depends on browser/OS for the style of emoji, but browsers also differ in the way they render font unicodes. This means that overflow never happens on some configuration, and in a few of them it always occur.

The size of emoji picker container is good and we want to keep it fixed, as it plays nicely with the rest of UI. For the size of emojis, as long as we rely on font unicode, we have to live with the different sizing.

This commit suggests a new way to manage overflow which doesn't show a scroll bar while letting browser/OS choose their way to render emojis: we detect whether emoji tabs overflow, and when so it fills as most emoji it can without overflow. Navbar has many "panels", and switching to panels happen either manually (click on >> and << buttons) or with scrolling of emoji picker without any search.

Commit also makes the following minor improvements:
- category section position sticky was not completely hiding emoji list below (e.g. on Chrome macOS). This is fixed with a `.align-self-stretch` on the section
- emoji categories are centered with emoji picker

Task-4413819

-------------

_(note: size of emoji in navbar is artificially bigger to simulate some rendering in few browser/OS that have always overflow)_
Before / After
![before](https://github.com/user-attachments/assets/12375001-2c2d-4bfb-90c9-d4189c799370) ![after](https://github.com/user-attachments/assets/0d5e07ff-2d18-4f0b-93a8-a8b9aefe68b1)

…ing taxes

Steps to reproduce
==================

- Create a company in Canada with the canadian fiscal localization
- Configure the avatax sandbox credentials
- Create a new fiscal position in the USA that uses the avatax API
- Create a USD pricelist
- Create a warehouse in Cleveland Ohio
- Create a salesorder with an Ohio based customer and the USD pricelist
- Select a storable product with an invoicing policy on delivered
  quantity
- Set the avatax category of the product to "Hand tools"
- Select the warehouse just created on the sales order
- Click on the "Compute taxes" button
=> The tax is set to 1%
- Confirm the sales order
=> The tax is still set to 1%
- Validate the delivery and create + confirm a new invoice
=> The tax is now 2.25%

Cause of the issue
==================

When computing the addresses to send to Avatax, the stock move addresse
was used, but at this point, they have not yet been created

Solution
========

We now use the warehouse from the sales order. This is only a
best-effort estimation of where the products will ship from. It's
possible products ship from a different warehouse than warehouse_id. For
example, you can change the default delivery route to pull from a source
location in a different warehouse. However, this is probably not a
common configuration. In the end, the only way to know for sure is to
run the inventory-related code, which we want to avoid just for tax
computation. Finally, it's also possible for users to change the
warehouse manually after the order is confirmed. This can also
potentially change taxes, and there's no way to anticipate this.

The account.move code will continue to pull the warehouse from the
stock.move, because we know it will be created before the invoice. Note
that even on account.move the shipping address remains an estimation for
products with an “invoice on ordered” invoicing policy.

opw-4073701

## Issue:
- Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax.

## Steps to reproduce:
- Create a new invoice and add a line with an 8% tax.
- Validate the invoice and export it as XML.
- Upload the XML file as a vendor bill.
- The vendor bill incorrectly shows two "8% taxes" instead of one.

## Solution:
- The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8
- In `17.0` we introduced this Extract method  `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`.
- We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it.
- I removed the extra code introduced during the forward-porting.
- Refactored the related code to ensure compatibility with the new changes in `17.0`.

OPW-4198016