[FIX] mail: avoid error on service worker push subscription change

Sometimes, the `pushsubscriptionchange` event is called without an
`oldSubscription` defined, which can lead to an error occurring inside
the  service worker.

Steps to reproduce:

1. Enable notification in Odoo.
2. Reset the permission in the Chrome interface
3. Re-enable the permission inside the discuss systray by clicking on
the Odoobot message.
=> The pushsubscriptionchange is called without an oldSubscription


[FIX] mail: ir_cron_web_push_notification are now more robust

With a user having 5 registered devices for push notifications
if a browser registers with an endpoint that has a wrong domain
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX
the cron job cannot resolve the invalid domain of the endpoint and ends
up disabling it.


[FIX] mail: push_to_end_point method to support .invalid TLD

if a browser registers with an endpoint that has a TLD `.invalid`
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX

The TLD `.invalid`[1] is intended for use in online construction of
domain names that are sure to be invalid and which it is obvious at a
glance are invalid. The cron job cannot resolve the invalid domain of
the endpoint and ends up disabling it.

So we need to unregister a device with an endpoint with a `.invalid`
TLD.

[1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2


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

### Steps to reproduce:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

### Step to reproduce:
1. Create db in version 17.0 and create a many2one field
   with ``mail.partner.device``
2. neturalize the db. All records of res.users will be vanish due to  ``TRUNCATE mail_partner_device CASCADE;``

### Issue: 
during neutralize if there is any custom/studio field many2one with ``mail.partner.device`` even if the mail partner device
record won't used it in particular model still it will wipe out all the records of that model on neutrilizing
which can issue during testing on neutrlized db 

**To fix it :** 
 [here](https://github.com/odoo/odoo/pull/133560/files#diff-284b40b100919f9b1d4f7bee50740387fea5f11815210baa5f6de9cbf317ca6dR14) want to delete only partner device. So, adjusted query using ``DELETE FROM mail_partner_device`` instead of truncate.  

below traceback will generate due to this during upgrade.
```
Traceback (most recent call last):
  File "/home/odoo/bin/misc/update_module_list.py", line 25, in <module>
    env["ir.module.module"].update_list()
  File "<decorator-gen-87>", line 2, in update_list
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 71, in check_and_log
    log_data = (method.__name__, self.sudo().mapped('display_name'), user.login, user.id, origin)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1188, in __get__
    raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: res.users(1,), User: 1)
[ERROR]::Error during the upgrade:
```


opw-5443072
upg-3712726

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185