Before this commit, a maximum call stack traceback occurred when accessing the chat tab of the messaging menu on iOS when many chats were present. On chrome and firefox, no traceback occurred, but the menu took a long time to open.

Threads shown in the messaging menu rely on the `menuThreads` store property, which had two issues:
- It was a computed field done on the many side of the relation, while relying on the inverse (thread) side would be much faster.
- The sort function was triggered for each thread inserted or removed from the relation. The sort function is not trivial, and accessing sort fields through the reactive proxy is very slow.

This commit fixes the issue by:
- Updating the `menuThreads` property to use an inverse instead of a complex compute.
- Debouncing the array sort to ensure it is executed only once when the relation is properly filled.

task-4794325

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Steps to reproduce:
1. Pair an IoT box
2. In the IoT form view, click on any device, then click back to return to the IoT form view.
3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form.

Expected behaviour:
- When a new request is made, the previous request is cancelled.

Actual behaviour:
- The previous requests remain active, and eventually no further requests are possible due to browser limits, causing action calls to timeout.

This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called.

Before the fix (action times out due to many stuck event calls):
<img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" />

After the fix (action succeeds):
<img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" />

**Steps to reproduce:**
- Install Accounting and l10n_mx_edi_stock_30
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)

- In Accounting settings, select "Solucion Factible" as PAC
- Create a product:
  * Product Name: XYZ
  * Product Type: Storable Product
  * UNSPSC Category: 25101929 Mobile office van
  * Tariff Fraction: 0101299999 Los demás.
  * UMT Aduana: Units
  * Weight: 1.00

- Go to "Inventory / Operations / Transfers / Deliveries"
- Create a delivery:
  * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA)
  * Product: Product XYZ
  * Transport Type: Federal Transport
  * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT)
  * Gross Vehicle Weight: [anything]
  * Distance to Destination (KM): [anything]
- Validate the delivery
- Generate Delivery Guide
=> CFDI document should be created and signed by the government
- Print Carta Porte

**Issue:**
The "CCP ID" in the PDF is different than the one in the CFDI sent to the government.
Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF.
This also leads to a different QR-code in each PDF.

**Cause:**
When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed.
The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier.
Each time the compute method is called, a new identifier is generated.

**Solution:**
When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document.

opw-5208648

### Steps to reproduce:

- In the settings enable "Product Packagings"
- Create a product KIT with 2 variants (for instance add the color attribute with the "white" and "black")
- Crete a kit bom for this product: 1 x COMP
- Go to Inventory > Configuration > Products > Product Packagings
- Create a new packaging for KIT (white) with barcode XXX
- Create a receipt for 1 unit of KIT (white)
- Go to the barcode app > scan your receipt
- Scan XXX
#### > Error: Record product.product doesn't exist in the cache, it should return by the server

### Cause of the issue:

Since commit c3fdc6e07fe7704340691fcc1bd7ed3cfb19abaf, the packaging related to KIT (white) is added to the barcode cache by the `_get_stock_barcode_data` (which was necessary to solve the related issue):
https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode_mrp/models/stock_picking.py#L9-L18 However, the `KIT (white)` product itself is not be present in the cache as only products present in move lines are added the barcode cache when opening the operation in barcode:
https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/models/stock_picking.py#L93-L95 This causes the issue as the package scans find the packaging in the barcode cache but can not recover its related product from it aswell: https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L988-L990 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L1251-L1252 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/lazy_barcode_cache.js#L75-L80

opw-4852875