Before this commit, when opening message reaction menu in a chat window, clicking on ESC was closing the chat window.

Steps to reproduce:
- as Mitchell Admin, open a chat window of channel General from click on messaging menu in systray
- add an emoji reaction to the last message
- click on composer to have focus on it
- mouse hover the reaction then click on emoji reaction tooltip
- press ESC when the message reaction menu is open

=> it closes the chat window instead of message reaction menu.

This happens because when opening the message reaction menu, the dialog is mounted. It detects dropdown is closed after a delay, and when closing the dropdown it recovers the focus before the opening of dropdown, which could be the composer of chat window. In the case when the focus was on composer, pressing ESC on message reaction menu will close the chat window due to composer being focused.

This commit fixes the issue by immediately setting the dropdown state to close when clicking to open message reaction menu, so that it won't recover the old focused element such as the composer.

---------

This commit also fixes a related minor bug when closing the message reaction menu then hovering the reaction was not showing the dropdown/tooltip of reaction. This happens because the `useHover()` hook was not aware the click on dropdown content closes the hovered ref, thus it kept internally thinking the item is hovered so it wasn't updating UI to open dropdown or reaction.

This is fixed by adding a parameter `stateObserver` to help the `useHover()` hook to re-check whether the targets are present on UI. Thanks to this, it can detect whether the currently hovered target has been removed, thus invoking the behaviour to mark is as no longer hovered.

task-4351992

Before
![before](https://github.com/user-attachments/assets/de6c8dc2-6c96-4399-8ec0-81d81cbd2dd7)

After
![after](https://github.com/user-attachments/assets/26607676-1210-4e1e-9968-ab7274c83159)

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)

**Issue:**
The client gets an error while accessing an employee's payslips if that employee has a contract based on attendances with a null allowed value for its working schedule.

**Expected:**
The client should be able to access the payslips regardless on the working schedule value, even blank.

**Steps to reproduce:**
- Activate Payroll app and presence based on attendances in employees' settings;
- Open or create a contract through an employee's file;
- Set "Work Entry Source" to "Attendances" and leave "Working Schedule" empty;
- Try to access the employee's payslips through the action button.

**Cause:**
No timezone found on a contract's calendar because the calendar is null. [https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141](https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141
)

**Fix:**
Add a default value on `'UTC'` if no calendar has been found.

**Linked:**
Community PR :
https://github.com/odoo/odoo/pull/186222

opw-4268672

…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