Step to reproduce:
- Install MRP.
- Set up a warehouse for a 3-step manufacturing process.
- Create 2 products: serial number (SN) tracking and Lot with lot tracking.
- For the SN product, create a BOM requiring Lot as a component (2 Lot for 1 SN)
- Add  few  lots (2 qty in each lot)  for Lot for in hand quantity
- Create an MO for the SN product (2 qty).
- Two transfers are created. Validate the one for pre-production (ready state).
- In the MO, validated lots (2 lots) are assigned.
- Mass produce the SN. The move is picked.
- Scrap the MO-1 for lot 1 (2 qty), mark should replenish.

Observation:
- A transfer is created for pre-production but does nothing when validated.
- The "Check Availability" button does not work as expected.

Cause:
- when scrapping the move in production, the linked move_line are picked by
mass production, hence the linked lots are not considered for reservation.
i.e. if a move line is picked somehow(here, by mass producing), and then if we
scrap a move, the linked line with that lot is not unlinked.

Fix:
- when scrapping a move in production, we unpick the related move line, so it
will be considered for availability checks.

opw-5213272

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

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737