The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations:

1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order

2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000.

3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans.

Benchmark (page 1 load):

_prepare_tasks_values (milestone + count, excludes lazy main search):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.294s    | 0.230s   |
| 1,500,000 |      2,000 | 0.511s    | 0.222s   |
| 3,000,000 |     12,000 | 1.129s    | 0.258s   |
| 6,000,000 |     24,000 | 2.388s    | 0.261s   |
| *6,000,000|     24,000 | 2.015s    | 1.976s   |

*6M measured while navigating last page (full count triggered).

Main search query (ORDER BY fix):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.525s    | 0.013s   |
| 1,500,000 |      2,000 | 0.685s    | 0.017s   |
| 3,000,000 |     12,000 | 1.479s    | 0.040s   |
| 6,000,000 |     24,000 | 3.121s    | 0.043s   |
| *6,000,000|     24,000 | 7.562s    | 3.781s   |

Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5
Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b
*6M measured while navigating last page (high offset).

- opw-5478903

Forward-Port-Of: odoo/odoo#258064

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5

Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised

Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
    - Clear the Warehouse field (set it to False)

- Create a purchase order:
    - Set "Deliver To" to the operation type with no warehouse
    - Add any product
    - Try to confirm the PO

Problem:
A traceback is triggered:
```   return self.parent_path.startswith(other_location.parent_path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```

`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False

Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).

opw-6253817

Forward-Port-Of: odoo/odoo#268317

Steps to reproduce:
- Create a storable product “P1” with Lot tracking
- Enable routes: MTO + Manufacture
- Create a BoM for the product:
    - Component: C1
- Configure the warehouse with 3-step manufacturing
- Have on-hand stock in WH/Stock with Lot 001
- Confirm a Sales Order for the product
- Confirm the generated Manufacturing Order and produce Lot 002
- In the "Store Finished Products" transfer, change the destination location from WH/Stock to WH/Stock/Shelf 1 and validate
- Check the Delivery Order reservation

Problem:
The move is reserved with Lot 001 instead of 002

When using a 3-step manufacturing flow (MTO + Manufacture), if the user manually changes the destination of the "Store Finished Products" transfer to a sublocation of WH/Stock (e.g. WH/Stock/Shelf 1), the MTO link between the production and the delivery order was incorrectly broken, causing the delivery to reserve existing stock instead of the freshly produced lot.

Root cause: `_skip_push()` only skipped push logic when the downstream move's source was a child-or-equal of the current move's destination (`m.location_id._child_of(self.location_dest_id)`). When the destination was changed to a sublocation (WH/Stock/Shelf 1), this check failed, so `_push_apply()` ran, found the delivery's source (WH/Stock) was not a child of WH/Stock/Shelf 1, and called `_break_mto_link()`, clearing `move_orig_ids` on the delivery move. The delivery then fell back to make-to-stock reservation and picked an unrelated lot.

opw-6197212

Forward-Port-Of: odoo/odoo#269141
Forward-Port-Of: odoo/odoo#268783

**Steps to reproduce:**
* Install `l10n_fr_pdp` module.
* Activate French eInvoicing in demo mode and enable "Participate in the pilot phase".
* Create an invoice for a French client and send it via the French E-Invoicing.

**Observed behavior:**
* A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`.

**Cause:**
* `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2.
* Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure.
* Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step.

**Fix:**
* Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2.
* Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`.
* Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message.

IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63

opw-6289723

Forward-Port-Of: odoo/odoo#269515