## Issue:
Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling.

## Reason:
During the down payment process, the PoS adds new lines to the sale order. These are added during the order validation stage. However, the updated order lines are not written back to IndexedDB.

If the user attempts to settle the order without reloading the session or clearing the cache, the PoS relies on stale data from IndexedDB. This causes Odoo to see outdated `order_lines`, usually only the original item(s), leading to incorrect behavior such as product quantities resetting to 0.

## Fix:
To ensure data consistency, we explicitly remove the affected sale orders from IndexedDB after the down payment is completed. This forces the PoS to re-fetch the updated order from the backend.

The re-fetch happens through the `missingRecursive` function, which will retrieve the complete and up-to-date sale order data, including the new order lines, ensuring accurate behavior during the settlement process.

## Steps to reproduce:
1. Create a service product with "Ordered quantities" as the invoicing policy.
2. Create a quotation using this product.
3. Open the PoS.
4. Click "Actions" → "Quotations" → select the quotation.
5. Choose the "Down Payment" option (any type) and set amount/percentage.
6. Pay the order.
7. Again, go to "Actions" → "Quotations" and select the same order.
8. Click "Settle the order".
9. At this point, Odoo will incorrectly reset product quantity to 0.


OPW-4811612

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

This reverts commit 2094747717be

Versions
--------
- 18.0+

Steps
-----
1. Create a service product that creates a task on order confirmation;
2. add an attribute that does not create variants;
3. add the product to an order;
4. confirm the order.

Issue
-----
1. The task is named as the attribute.
2. The line's `display_name` shows the attribute instead of the product.

Cause
-----
Commit 2094747717be removed the extra new line that was added before attribute-based line descriptions for custom attributes and attributes that create no variants.

This did not impact the task or display name in previous versions, as the default sale order description started with the product name, and could be replaced.
But as of 18.0, while the default sale order description still starts with the product name, it's no longer possible to replace it, hence it gets skipped to get the first line of the editable description, which in this case is the attribute name.

Solution
--------
By re-adding the empty line before the attribute descriptions, the display & task names will fall back on the product name.

See commit 47d223759f07 for display name & c3877b2acd74 for task names.

Also adds a test to prevent regression.

opw-4792351

When mixing cross-dock (XD), MTO and MTS products, it may lead to
incorrect partners on the pickings.

To reproduce the issue:
1. Enable Multi-Routes
2. Edit the warehouse: 2-steps reception, 2-steps delivery
3. Unarchive MTO route
4. Setup 3 products:
   - Storable
   - Routes:
     - All with buy
     - One MTO
     - One XD
   - Same supplier
5. Create and confirm one SO for each product (starting with XD one),
   each one with a different customer
6. Validate the generated replenish
7. Confirm the PO
8. Process the receipts

Error: The internal pickings have the same defined partner, the
customer of the XD product.

There are two issues:
- The destination address of a purchase is defined on the PO level,
not the POL one
- When looking for a PO, the `_run_buy` mechanism doesn't filter on
the destination address

This explains why:
- All purchases are gathered on the same PO
- On the internal pickings, we will find the first destination address

Even though the first point is convenient, since the destination
address is defined on the PO level, it leads to incorrect results.
However, changing this on stable is too risky. The only (and sad)
thing we can do so far is the creation of an ICP that would split
all PO based on their destination address. On master, this address
will be defined on POL level.

OPW-4552316

If a user tries to open a combo product on the website and the combo item
has been deleted, a traceback will appear.

Steps to reproduce the error:
- Install ``website_sale_stock`` module
- Create ``Product A`` > product type: ``Goods`` > Save
- Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) >
  Add ``Product A`` in combo item
- Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A``
- Delete ``Product A``
- Go to Website > Shop > Open ``Product Combo A``

Traceback:
```
File "/home/odoo/src/odoo/addons/website_sale_stock/models/product_combo.py", line 25, in _get_max_quantity
    return max(max_quantities) if (None not in max_quantities) else None
ValueError: max() iterable argument is empty
```

https://github.com/odoo/odoo/blob/4d3b220b0ec6e718f962979b3f271ea161997322/addons/website_sale_stock/models/product_combo.py#L21-L24
Here, when the user deletes the product, ``self.combo_item_ids`` becomes empty,
resulting in ``max_quantities`` being an empty list ([]),
which causes the above traceback.

sentry-6589160704

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

Issue Before This Commit:
============================

In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.

Steps to Reproduce:
============================

- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
  - The lines are grouped by Source Location.
  - If you edit by-product line then user has option to edit source location.
  - If the MO operation type has Source Location scan as mandatory,
    user can't edit by-product line.

With This Commit:
============================

- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
  users can still edit by-product lines.

This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.

task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)