- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However, this filtering was performed inside a loop iterating over all work orders, even though the result of the filtration did not depend on any single work order.

Before this commit:
- The filtration was executed repeatedly for each work order, despite being deterministic.
- This unnecessary repetition caused performance degradation and multiple redundant updates to the `picked` field of the same moves, resulting in fake or redundant database writes.

After this commit:
- The filtration logic has been moved outside the iteration, ensuring that the update to the moves is performed only once, improving overall performance and preventing redundant updates.
- The `end_all` method is now executed on the entire recordset of work orders at once, instead of being called individually for each iteration.


The benchmark below is done on a recordset of workorders of size **500** and the number of moves returned from the filter were **100**. It set the picked field to be **True** for every workorder in the recordset, potentially triggering recomputation of some of the fields and doing more redundant SQL queries. 

opw-5092636


### Benchmark Results 

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **Memory Error**
| **After this Commit** | **22 seconds**

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

Forward-Port-Of: odoo/odoo#233102

Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469

Forward-Port-Of: odoo/odoo#224002