Description of the issue/feature this PR addresses:

Related to this task: [4720354](https://www.odoo.com/odoo/project.task/project.task/4720354)
This issue considers a multi company environment, where two companies are set to have different currencies. If an event is created, it belongs to one of these companies. Tickets from either companies can be added to the event's registration, and the end user will see the price for these tickets in the currency of the website, despite some tickets having a different  currency set.

Current behavior before PR:
The registration wizard displays the prices of tickets at face value, i.e. without any conversion. A ticket with its price being 100 euros will be displayed as 100 dollars.

Desired behavior after PR is merged:
The wizard would display the converted amount of the euros tickets in dollars. The 100 euros will be $77.92

Steps to reproduce the issue:
- Create a second company with a currency different than the current company (ex: current company uses dollars, new company uses euros)
- Make two products of type 'event', one for the dollar company and one for the euro company
- Create an event, add two tickets (related to the products)
- Click the register button on the website, see the prices of both tickets, with the modified view, the euro ticket should have its amount converted to the website's currency.

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

*: sale_mrp, sale_purchase_stock

Issue:
Product availability and forecasted lines are not correct when handling multi-warehouse, multi-step deliveries; specifically for manufactured and purchased products with future delivery dates. Product availability for final delivery is "Available" when it should be "Exp."
The forecasted lines show the reserved move as the MO, when it should be the interwarehouse transfer.

This behavior occurs from 17.0 onward, due to [this](https://github.com/odoo/odoo/commit/57d8590) refactor of `_get_forecast_availability_outgoing()` and [this](https://github.com/odoo/odoo/commit/2dad4a5) refactor of StockForecasted.

Assuming we have two warehouses, WH1 and WH2, where WH2 is supplied from WH1, `_get_out_move_reserved_data()` calculates the reserved out quantity, reserved move, and move state. For manufactured/purchased products:
* The products will be reserved from the WH1 MO. WH2 delivery will not recognize the interwarehouse transfer as its in move.
* The forecasted date for the WH2 delivery becomes "Available" when it should match the WH1 transfer date.
* The finished products should be reserved from WH2, which will be transfered from WH1.

This commit refactors `_get_report_lines()` in StockForecasted to encapsulate the reserved stock logic for easier inheriting. It also adjusts the forecast report view to account for case where both reserved move and in move are set.
* We add a check to see if the reserved move has a `production_id` (MRP) or `purchase_line_id` (purchase)
* If true, append the correct in move and reserved move to the forecast line.

Before this commit: 
Product Availability is not consistent (WH2/OUT is "Available" when should match WH1/OUT).

<img width="1915" height="356" alt="image" src="https://github.com/user-attachments/assets/bef9cc3c-b98c-4385-a1bb-aaa4b1e00d71" />

Forecasted report shows the "MO" move as the reserved move.
<img width="1899" height="326" alt="image" src="https://github.com/user-attachments/assets/05a75426-9811-435c-8dad-25a405e8ef2d" />


After this commit:
Multi-warehouse deliveries will have the correct in moves and reserved moves and will reflect correctly in the forecast report.
The products availability will also be consistent, showing "Exp mm/dd/yyyy" for each delivery.

<img width="1910" height="388" alt="image" src="https://github.com/user-attachments/assets/3ee9059e-3202-4409-8dc7-b25222b8f817" />

Forecasted report shows the "IN" move as the reserved move.
<img width="1912" height="294" alt="image" src="https://github.com/user-attachments/assets/e4e4418d-0de7-43fa-8b5a-9267e6a91b15" />


Steps to Reproduce:
* Enable multi-step routes
* Create two warehouses (WH1 and WH2)
  * Both 3-step delivery only
  * WH2 -> resupply from WH1
* WH2 routes:
  * MTO unarchived
  * WH2: Supply product from WH1 -> check "Sales Order Line"
* Create product with routes "Manufacture" and "MTO" + BOM
  * "Buy" and "MTO" for purchases
* Create SO with product
  * show "Route" on SO line
  * set "Route" to "WH2: Supply product from WH1"
* On "Other Info" tab, set:
    * Warehouse -> WH2
    * Shipping Policy -> As Soon as Possible
    * Delivery Date -> +10 days from current date
* Confirm SO
  * 7 delivery orders and 1 MO (or 1 PO) should be made
* For Purchase Only: Confirm the PO
* Go to Delivery Orders
  * show "Product Availability" on the lines
* Products availability for WH2 delivery will be "Available", WH1 delivery will be "Exp mm/dd/yyyy"
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**This is a backport of** https://github.com/odoo/enterprise/commit/f0e2cd2bd9ed89ab2cb961106869088a771d212a


**PROBLEM**
When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`)

**STEP TO REPRODUCE**
1. install the accounting module
2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file.
3. make sure the file will be imported in multiple batches (reduced the batch size if necessary) and click on import.
4. notice how only the first batch was imported.

**CAUSE**
In python,
The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list. (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`)

In JS,
all entry in messages are treated as errors, and the import is interrupted. (see `odoo/addons/base_import/static/src/import_model.js`)

The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message.

**FIX**
Remove the problematic message entry.

opw-4823808
opw-5441739

**Problem:**
Searching for text that only exists in a setting's sub-field content (e.g., "qr" matching "Add QR-code link on PDF") fails to find the setting when searching from a different app tab in General Settings. The same search works when already on the correct app tab.

**Steps to reproduce:**
1. Open Settings (General tab is selected)
2. Search for "qr"
3. "Invoice Online Payment" setting is not found
4. Navigate to Accounting settings tab
5. Search for "qr" again
6. Now the setting appears

**Current behavior:**
Settings from non-selected apps are not found when the search term only matches sub-field content (text inside the setting body).

**Expected behavior:**
Search should find settings across all apps regardless of which tab is currently selected.

**Cause of the issue:**
SearchableSetting collects search labels in two phases: the setting's own label and help text during setup(), and sub-field text from span[searchableText] DOM elements during onMounted(). However, visible() is evaluated during render via t-if, which runs before onMounted. When an app first renders due to a search (it was previously unrendered because its tab wasn't selected), visible() only has the incomplete label set and returns false, preventing the setting div from rendering. This creates a chicken-and-egg problem: the DOM needed for label collection never exists because visibility check fails without those labels.

**Fix:**
A reactive labelsReady flag defers visibility filtering until onMounted has had a chance to collect all DOM-based labels. On the initial render, visible() returns true unconditionally so the DOM exists for label collection. The state change then triggers a proper re-render with the complete label set.

opw-5946625

## Issue:
Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees.

## Steps to reproduce:
1. Connect to Outlook and Sync for user A.
2. Create a recurring event from Outlook.
3. Connect into a user B with access to the event and edit all the events from the series.
4. Run the scheduled action to sync user A.
5. Many emails are going to be sent to the attendees from Outlook.

## Solution: 
With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook.

opw-4374503