### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#117577
Forward-Port-Of: odoo/enterprise#113227

*:mrp_subcontracting{,_quality}, quality_control
**Issue**:
In subcontracting, if a quality check of type quantity failed, the associated mo quantity produced is reduced. This is an issue since it will, by extension, reduce the consumption of the component. Therefore, the stock of the component become incorrect.

**Steps to reproduce**:
- Create two tracked products (final and component)
- Create a BoM for the final product using the component (1:1 ratio), with subcontracting
- Create a quality check for that product:
	- Control per quantity
	- Operations type: receipts
- Create a PO for the final product:
	- With a quantity of 10
	- With the associated partner be the one mentioned in the subcontracting BOM
	- Confirm it
- Open the associated receipt
- Perform the quality check and fail 4 products
- Validate the receipt by creating a backorder
- Confirm the backorder
- Check move history -> The move associated to the component will have a quantity of 6 instead of 10.

**Cause**:
While failing a quality check:
https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_mrp/models/quality.py#L56 https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_control/models/quality.py#L471

The `product_uom_qty` of the move of the po will be reduced. Therefore, the subcontracting mo quantity is reduced too: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L140-L143 https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L116-L119

And ultimately reduces the raw move quantity:
https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/wizard/change_production_qty.py#L65

**Additional note**:
This commit also reverts the fix of c4e10e9fa90562b16d515f62910e094f77497f66 since it ensured the correct production was reduced. However, this commit ensures that production is not reduced at all, making the previous fix obsolete.

opw-5427873

Forward-Port-Of: odoo/enterprise#114358

*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.

**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
  - Operation type: Receipts
  - Control per Quantity
- Create a PO for the final product:
  - With a quantity of 3
  - With the associated partner be the one mentioned in the subcontracting BOM
  - Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product

-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available

**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94

When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471

This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320

As a result, the reduction could be applied to a production unrelated to the inspected lot.

**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.

opw-5427873

Forward-Port-Of: odoo/enterprise#104424

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118403

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870