When a stock move's UoM differs from the product template's UoM, the report aggregation incorrectly shows data for both UoMs of stock move.quantity on the same graph. All moves should be normalized to the UoM of the product for which we are viewing the forecast.

We can do this with:

`m.quantity * move_uom.factor / pt_uom.factor AS quantity`

If the UoMs of the stock move and the product template are identical, as is the case most of the time, this simply multiplies by one, and the query behaves exactly as it did before. But if the units are distinct, the move UoM is converted into
the product template UoM so that the data for stock move quantity is normalized to one shared unit across the entire forecast graph.

**E.g.**:

m.quantity == 500g
m.UoM == g
m.UoM.factor == 1
pt.UoM == kg
pt.UoM.factor == 1000

500g * 1 / 1000 ==> .5kg

**Steps to Reproduce on Runbot**:
1. Create a product which uses kg and g. 
2. Confirm and Validate a receipt for this product (10 kg for example). 
3. Confirm a second receipt for this product in the same UoM kg. 
4. Confirm and Validate a delivery for this product with UoM g (500 g for example).
5. View the forecasted graph for the product, and you will see that the y axis is scaled on grams ~500, and the current / future stock moves in the report are still scaled based on kg. 

opw-6234066

Forward-Port-Of: odoo/odoo#266811

### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#117879