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" />

Forward-Port-Of: odoo/enterprise#98985

Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.

Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
     contenteditable="true">
  text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.

Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.

Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.

opw-5184309

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

Forward-Port-Of: odoo/odoo#232910

Versions
--------
- 18.0+

Steps
-----
1. Have a product attribute with variant creation set to never;
2. have product using only this attribute, with only a single value;
3. open website editor on /shop;
4. enable add-to-cart button & save;
5. use button on the aforementioned product at least twice.

Issue
-----
Each time the product gets added, a new line is created.

Cause
-----
Because there's only a single value, the product configurator doesn't pop up by default when adding the product to the cart. Without the configurator pop-up, the `_cart_update` method doesn't receive any `no_variant_attribute_value_ids`, which are used find a matching line if the product template has any `no_variant` attribute.

Solution
--------
Instead of checking `product.product_tmpl._has_no_variant_attributes()`, to see if we should attempt to match `no_variant_attribute_value_ids`, check if the added product has any `no_variant` attributes that have more than one value or are optional (multi-checkbox). If not, a `no_variant` product behaves the same as a single-variant product.

opw-5093175
opw-5137351

**Steps to reproduce:**
- Install Accounting and l10n_mx_edi_stock
- 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: Goods
  * 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

Forward-Port-Of: odoo/enterprise#98920

### Issue:

Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.

### Steps to reproduce:
- Create a kit product with a kit BOM:
    - 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation

### Cause of the issue:

Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does,  the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921

### Fix:

In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.

opw-5100026

__Before this commit__:
1. Set a right-to-left language (e.g. arabic) as default language on the website
2. Open the website editor
3. Select an element of the page => The editor overlay border are not in the correct place
4. Open the snippet dialog => The snippets are not visible.

__Cause__:
Since [this commit][1], `lang` in `session.bundle_params` is (correctly) set to the `request.lang.code`.
Consequently, `website.assets_all_wysiwyg_inside` is fetched with the frontend language code in the `searchParams` which shouldn't be the case especially if the website language direction is not the same as the backend one.

__Description of the fix:__
The `getBundle` method from outside the iframe is used instead of the frontend one to retrieve the URL of the bundle that matches the language direction of the builder.

Backport and adapt the test from [this commit][2].

[1]: https://github.com/odoo/odoo/commit/e10852a45f10c55a833c33a51956e5f
[2]: https://github.com/odoo/odoo/commit/7bcd56c07852b77849b05184200c48a

task-5246916
opw-5214703

**Description of the issue/feature this PR addresses**:
This pr is to avoid duplicated taxes when the demo data is installed.

**Steps to reproduce**:
1. Install l10n_ar_withholding module with demo data.
2. Take position in "(AR) Responsable Inscripto" company.
3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes".
4. Delete the filter "Sale or Purchase".
5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"].
6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy).

**Current behavior before PR**:
Duplicated taxes are created when demo data is installed.
<img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" />

**Desired behavior after PR is merged**:
No duplicated taxes are created when demo data is installed.

_Task latam side_: 1360.
_Task Adhoc side_: 57627.


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