Issue:
-------------------------------------
Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs option was enabled in the Manufacturing settings.

Steps to Produce:
-------------------------------------
- In Manufacturing settings, disable the Show Reserved Lots/SNs option.
- Create a Manufacturing Order and reserve component lots.
- Go to the barcode app
- Lots/SNs appear even though the Show Reserved Lots/SNs option is disabled.

After this Commit:
-------------------------------------
A correct value is now passed to the condition controlling the lot and serial number visibility.
Lots/SNs are shown only when Show Reserved Lots/SNs is enabled in Manufacturing settings, or when they have been picked or scanned, helping users focus only on relevant information and reducing the chance of picking or scanning mistakes.

Task Id: [3908929](https://www.odoo.com/odoo/project/966/tasks/3908929)

Forward-Port-Of: odoo/enterprise#62853

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

[REV] account_iso20022: Wrong XML generated for Switzerland

This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da.

This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt.

The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix.

ticket-4535542

=======================

[FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file

https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard.

Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file.

ticket-4535542

Forward-Port-Of: odoo/enterprise#98918