## Issue:
- When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English.

## Steps To Reproduce:
- Create a storable product.
- Define a vendor for this product and add a delivery lead time.
- Navigate to the product template and click on the "Replenish" button.
- Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time.
- Change the language of the database to a different language.
- Repeat the replenish process.
- Observe that the schedule date is not calculated correctly.

## Solution:
- Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons..

opw-4199660

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

Context:
Every Behavior in Knowledge was a new App based on the config of the main Odoo
App.

Among shared resources are registries and services. In particular, the
`main_components` registry is used to mount components, and, for the purpose of
the following example that registry is used by the `popover_service`.

Another thing to note is that the template compilation involves a reference to
the App, and all ComponentNode have an app property which is the app that was
used to compile its template.

Issue:
Now all pieces together in a problematic example case:
Creating a new popover from a Behavior App involves the `main_components`
registry:
- Create a PopoverController (position logic (wrapper)).
  It is created within the main App through the registry, and its lifecycle is
  managed by the main App Scheduler.
- Fill it with a Custom Component (business logic).
  It is created within the Embedded Component App, and its lifecycle is managed
  by the Embedded Component App Scheduler.

Both schedulers lifecycle handling are not synchronized, and at some
indeterministic point one of the Apps will crash during the manipulation
of that popover.

Solution:
Use the new "subroots" OWL feature instead of using sub-apps, so that all
templates are created from the same App, and the scheduler is the same for all
components. This also has the advantage of not having to re-compile all
templates for every Behavior.

task-4300215

Forward-Port-Of: odoo/enterprise#73224

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system
Use case:
- In an MX Company with PAC Quadrum
- Enable currency USD
- Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148
- Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16%
- Confirm
- Make 2 partial payments of 100'000 MXN
- On the Invoice, click 'Update Payments'
- In the CFDI tab, on one of the payments, click 'Force CFDI'

Issue: Validation will fail with error
Note: This does not occur with other providers (Solucion Factibles)
```
Code : CRP20275
Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado,
convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto.
```

This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance

opw-4314798