Description of the issue/feature this PR addresses:
- The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable.
- This is incorrect because only CGST+SGST or IGST should be displayed, not all three.

Current behavior before PR:
- The receipt always displays CGST, SGST, and IGST columns at the same time.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/5c8487c7-c497-4c82-ad80-8cf0e98fbf38" />

Desired behavior after PR is merged:
- The receipt shows only the correct tax columns based on the transaction:
  - Shows CGST and SGST when GST applies.
  - Shows IGST when IGST applies.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/68d2fb58-9e15-4861-a71f-ccb2d978e544" />

Changes implemented in this commit:
- Added `t-if="l10n_in_hsn_summary.has_gst"` to CGST and SGST headers.
- Added the same condition to CGST and SGST values in the item rows.


task-5268935

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

Forward-Port-Of: odoo/odoo#236243

…f related line is complete

### Steps to reproduce:

- In the settings enable Lots & Serials and Batch transfers
- On the delivery operation types enable show reserved lots in the barcode tab
- Create a storable product tracked by lots and put 10 x lot1 in stock
- Create and confirm a delivery for 10 units
- Create a batch transfer with your delivery
- Process your transfer from the barcode app
- Scan one unit of LOT1 and put in pack
- Toggle sublines select the 0/9 subline without lots nor package
- Scan LOT1
#### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9

### Cause of the issue:

Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot.

opw-5340865

Forward-Port-Of: odoo/enterprise#101908
Forward-Port-Of: odoo/enterprise#101611

This commit fixes three issues occurring when editing nested `s_card` snippets.

**Problem 1 - Incorrect cover image detection**

Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image.
Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets.
Fix: Now the `querySelector` only searches among direct children of the snippet root element.

**Problem 2 - Ratio settings applied to all child cards**

Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards.
Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants.
Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet.

**Problem 3 - Parent image positioning leaking to children**

Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images.
Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`.
Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`.

task-5349540

Forward-Port-Of: odoo/odoo#239503
Forward-Port-Of: odoo/odoo#237587

**Steps to reproduce:**
* Install the **Italy – E-invoicing (l10n_it_edi)** module.
* Create a product with a non-zero cost price.
* Create a **vendor bill** for an Italian vendor using the **RC fiscal
  position**.
* Add the product with **unit price = 0**, apply **RC tax**, and set the
  **Origin Document Type**.
* Confirm the bill and click **Send to Tax Integration** to generate the
  XML in the chatter.
* Upload the generated XML through  
  **Accounting → Vendors → Bills → Upload**.

**Observed behavior:**
* The imported bill ignores the XML value **0.00** and uses the product's
  default price instead.

**Cause:**
* The XML’s `<PrezzoUnitario>` value is mandatory and may be **0**, but the
  code skipped it because `0.0` evaluates as falsy in the walrus
  assignment.

**Fix:**
* Always set the parsed `PrezzoUnitario` value (including **0.0**) on the
  invoice line.

ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/PrezzoUnitario  

opw-5322187

Forward-Port-Of: odoo/odoo#239904
Forward-Port-Of: odoo/odoo#239419

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

Forward-Port-Of: odoo/odoo#238901
Forward-Port-Of: odoo/odoo#229275

**Steps to reproduce:**
- (Firefox only)
- Go to any record which uses a chatter (e.g. Contact)
- Send message > Full composer > click the schedule message icon (lower right corner)
- Schedule the message in the future and click send
- You should see now a post in the chatter indicating that the message will be sent
- Now click Send message and repeat the above steps again to schedule a second message
- Whole page will be freezed
- Reloading doesn't help

**Issue:**
Infinite loop in reactive callback on firefox.
The code gets stuck in
```js
for (const callback of [...callbacks]) {
    clearReactivesForCallback(callback);
    callback();
}
```
because of
```js
const sortProxy2 = reactive(recordProxy, function sortObserver() {
    self.requestSort(record, fieldName);
});
this.fieldsSortProxy2.set(fieldName, sortProxy2);
```
which loops over `store._.ADD_QUEUE("sort", record, fieldName);`

(Forcing the `requestSort` only change the infinite loop into a recursion error)

The recomputation seems to be caused by a bad sorting here:
```js
this.scheduledMessages = Record.many("ScheduledMessage", {
    sort: (a, b) => {
        if (a.scheduled_date === b.scheduled_date) {
            return a.id - b.id;
        }
        return a.scheduled_date < b.scheduled_date ? -1 : 1;
    },
```
In the case both datetimes are equal the first condition doesn't properly catches it:
```
> a.scheduled_date - b.scheduled_date
> 0
> a.scheduled_date === b.scheduled_date
> false
> a.scheduled_date < b.scheduled_date
> false
> a.scheduled_date > b.scheduled_date
> false
```
Which make the ordering change on each sort iteration:
```
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,13", "ScheduledMessage,14" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
```
Chromium based browsers probably use a different sorting algorithm than Firefox, which seems to prevent the issue.

**Fix:**
Use `compareDatetime` to ensure the ordering is constant for the same datetime values.

opw-5367371

Forward-Port-Of: odoo/odoo#239745
Forward-Port-Of: odoo/odoo#239199