Currently, requests from the PoS UI are sent without any timeout, which can lead to indefinite waiting when the system is connected to a network but lacks internet access.

Examples:
- `sync_from_ui` can take more than 2 minutes to fail.
- Font CDN requests during receipt printing can take over 4 minutes to fail.
- In some cases, this causes receipt printing failure as well, even after several minutes (4-5 min) of delay.

This commit introduces a timeout for PoS UI requests to prevent such delays and improve responsiveness.

Additionally, font declarations are extracted from `web` into `point_of_sale`, and only the required fonts are included. This avoids unnecessary requests to missing CDN resources.

Additionally, this PR backports the following commits required to support this fix:
- https://github.com/odoo/odoo/pull/215130
- https://github.com/odoo/odoo/pull/220954
  Ensures the system continuously checks network connectivity and resumes synchronization once the connection is restored.
- https://github.com/odoo/odoo/pull/225743
  Prevents receipt printing from being blocked by logo loading issues and ensures the logo is displayed gracefully in such scenarios.

Task-6053404

| Font CDN request delay (~ 4 min)                   | `sync_from_ui` long request (> 2 min)            |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| <img width="400" src="https://github.com/user-attachments/assets/8ea8b3e4-7ffe-44bf-a4d0-7975f43a8f68" /> | <img width="400" src="https://github.com/user-attachments/assets/5f899cab-b022-4ed2-aa82-12e54ea34ea7" /> |

### Issue:
When invoicing a sale order for a kit, components tracked by quantity that are archived are excluded from the Cost of Goods Sold (COGS) calculation

As a result, the journal items for "Expenses" and "Stock Interim (Delivered)" are undervalued on the invoice, creating a mismatch with the inventory valuation which correctly includes the archived components' costs Odoo natively allows the delivery and usage of
archived components when they are part of a BoM

### Cause:
The Bill of Materials (BoM) explosion correctly bypasses the active check using `with_context(active_test=False)`
However, during the invoice posting, `_stock_account_get_anglo_saxon_price_unit()` filters the kit's components using a standard `search()`, but without disabling the active test
Consequently, archived components tracked by quantity are ignored when computing the final anglo-saxon price unit

### To reproduce the issue:
- Install `account_accountant`, `sale_management` and `mrp`
- Create a product category PC (Inventory Valuation: Automated)
- Create 3 Products:
  - Kit (Tracked: Quantity, Product Category: PC)
  - Kit_Comp01 (Tracked: Quantity, Product Category: PC, Cost: 10$)
  - Kit_Comp02  (Tracked: Quantity, Product Category: PC, Cost: 20$)
- Set Kit_Comp01 and Kit_Comp02 on hand's quantity to 1
- Create a Bill of Materials (Product: Kit, Type: Kit, Components: 1x Kit_Comp01, 1x Kit_Comp02)
- Archive Kit_Comp02
- Create and Confirm a Sale Order for 1x Kit
- Process the related delivery
- Create and Post the Invoice
- Check the Journal Items tab Before the fix, the lines `Expenses` and `Stock Interim (Delivered)` are 10$ instead of 30$

opw-6204621

**Problem:**
partial quantities in a dropship picking 
is not taken into account for the svl quantity
(it's always the full initial quantity)

**Steps to reproduce:**
- create a storable product with dropship route
- set the category as avco auto
- set a vendor in the purchase tab with a price of 10
- confirm a SO for a quantity of 2
- confirm the related PO with a unit price of 10
- on the dropship picking change the quantity to 1
- validate without backorder
- click on the valuation smart button

**Current behavior:**
- the svls have quantities of 2 and -2
- the related amls have debit/credit of 20

**Expected behavior:**
- the svls should have quantities of 1 and -1
- the related amls should have debit/credit of 10

**Cause of the issue:**
when creating the svls we use the move's product_qty
instead of its quantity
https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290

**fix:**
product_qty is expressed in the uom of the product
and quantity in the uom of the move so we need 
to add a uom conversion to the fix

opw-6113031

Avoid traceback when there is special hidden characters on the VAT numer, compact() method from stdnum does not process it.

We use regex to get only the number part for all the doc types

### Description of the issue/feature this PR addresses:

1. Create new contact
2. add cuit value (in the vat field). This one is copy from an external program with special hidden characteres

### Current behavior before PR:

There is a traceback and the user can not create the contact

```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/addons/l10n_ar/models/res_partner.py", line 123, in _get_id_number_sanitize
res = int(stdnum.ar.cuit.compact(self.vat))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '\u206030717808599'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30061:19)
at XMLHttpRequest.<anonymous> (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30124:27)
```
### Desired behavior after PR is merged:

Will let us to create the contact and validate the cuit no matter if it has or not an special character



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

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#120967

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Description of the issue/feature this PR addresses:

When an invoice has advance payment lines that exactly cancel the product lines (net taxable base = 0 per VAT aliquot), floating-point accumulation
in `_aggregate_base_lines_aggregated_values` leaves a tiny residual
(e.g. ~1e-12). This residual is truthy in Python, so `_get_vat()` adds
the aliquot entry to the result even though both `BaseImp` and `Importe`
round to `0.00`. The AFIP WSFE web service receives a non-null `Iva`
block with all-zero amounts instead of `null`.

## Steps to reproduce

1. Create an invoice with one or more product lines (IVA 21%, for example).
2. Apply an advance payment that fully cancels those lines.
3. Confirm the invoice and inspect the generated WSFE XML preview.
4. **Before fix:** `Iva` contains `{'AlicIva': [{'Id': '4', 'BaseImp': '0.00', 'Importe': '0.00'}]}`.
5. **After fix:** `Iva` is `null`.

## Root cause

`_get_vat()` checked the raw (unrounded) aggregated float values in the
filter condition:

```python
if ... and (values['base_amount_currency'] or values['tax_amount_currency']):




Current behavior before PR:

Desired behavior after PR is merged:




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

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up.

## Benchmarks
|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|6,262       |0.13s      |68            |0.12s     |68           |
|68,882      |0.60s      |112           |0.58s     |109          |
|432,317     |5.49s      |398           |3.68s     |309          |
|757,702     |15.33s     |1,141         |5.79s     |599          |

[opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)