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

# Issues

There are a total of 3 different flows by which we observe the common issue (name not updating in the fileviewer)

-----------------------------

### 1st flow
1. click on any image to preview it.
2. close the preview.
3. now just select the same document.
4. change it's name from the inspector and hit ENTER.
5. now keeping it selected, preview it again.
6. you will notice the file name has not been updated in the file viewer.

issue:
- the existing IF condition which is present only checks for the datapoint ID
  (which changes only when we replace the existing document with a new document).

reason:
- but in our case, since the document is same the ID remains the same.
- as a result, the code inside the IF block does not get executed and the
  document store is not updated.
  but we still need to update the document store with the newly updated document.

fix:
- we remove the IF condition so that we ensure that the document store is
  updated everytime we PREVIEW any document.

----------------------------------------------------

### 2nd flow

1. click on any image to preview it. (do not select it)
2. change it's name from the inspector and hit ENTER.
3. close the PREVIEW.
4. PREVIEW the same document again.
4. you will notice the file name has not been updated in the file viewer.

issue:
- for some reason the existing `record.save()` fails to save/update the root
  records.

fix:
- we find that record from the root and save it from the root.


----------------------------------------------------------

### 3rd flow

1. click on any image to preview it.
2. change it's name from the inspector and hit ENTER.
3. you will notice the file name has not been updated in the file viewer.

issue:
- the `previewStore` object is formed/updated only when we preview any document.
  it is this `previewStore` object which contains the list of documents to preview.
- but when we update the file name from the inspector, the code to update the
  `previewStore` is absent.

fix:
- on updating the values from the inspector, we now update the `previewStore`
  as well. which then goes on to update the name in the FILEVIEWER.

Task-4605750

Steps to reproduce:
-------------------------
1. Install Email Marketing Module
2. Create a new Mail List
3. Go to Mailing List Contacts
4. Select multiple contacts from list and click on Add to List button
5. From wizard select the newly created list and click on Add button
6. Open one of the contact added in step 4

Observation:
-------------------------
In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly.

Issue:
-------------------------
When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set.

Solution:
-------------------------
Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set.

opw-5055372

**Issue:**
For retired employees with AHV Insurance and variable pay, if their pay previously exceeded the exempt amount but is below the exempt amount on the current payslip, the AVS Salary will be negative, which is expected.

However, the AVS deduction is still calculated based on this negative amount and adds to the Net Salary, which is incorrect. Instead, no deduction should be applied.

**Steps to Reproduce:**
1) Install l10n_ch_hr_payroll_elm_transmission
2) Change to My Swiss Company and enable the Switzerland Fiscal Package
3) Go to Payroll > Configuration > AVS/AC Insurances
4) Create a new record, fill in the empty required fields with any data
5) Create a new employee
6) Create a contract for the employee starting January 1, with:
- Contract Type = Permanent contract with monthly salary
- Has Monthly Wage = True, 500.00
7) On the contract under Insurances tab, set:
- AVS/AC Insurance = The Insurance created in (4)
- AVS Special Status = Retired
8) Create a payslip for January, compute sheet, and post draft entries. -> AVSSALARY = 0 (Correct)
9) Change the Monthly Wage and repeat payslip creation and posting for the following months:
- February: 800
- March: 1,200
- April & May: 3,000
- June: 800
-> On the June payslip, notice that the AVS Salary is negative (correct) but the AVS Deduction is positive and adds to net salary (wrong)

**Solution:**
Modify the AHV/IV/EO contribution and AHV/IV/EO Employer contribution rules so that if the AVS Salary is less than 0, no deduction is made.

opw-5042175