Description of the issue/feature this PR addresses:

Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app:
https://drive.google.com/file/d/1C1nVdDHgCss7s7zyXDOpbMj0k79HlJBH/view?usp=drivesdk

Current behavior before PR:

When leaving the shopfloor app via a WO (WO setting -> Open MO), we set the a **context flag workcenter_id** in the the currentCaller.action.context to save the selected workcenter for breadcrumb logic. The same  **context flag workcenter_id** is used in the Manufacturing/workcenters view, when clicking on a workcenter. However, the intended use of the **workcenter_id flag** is different: 

- 1 From Manufacturing: Open shop floor with **only** workcenter_id selected + visible (no other workcenters visible).
- 2 From Shopfloor breadcrumb : Go to shop floor with all previous workcenters same as when leaving.

Additionally the current logic for setting the workcenter_id flag from the MrpDisplay record currently handles only the selection of isMyWO ([PR](https://github.com/odoo/enterprise/pull/52258))

Desired behavior after PR is merged:

Keep the same behavior when coming from Manufacturing/workcenters ([PR](https://github.com/odoo/enterprise/pull/67318)) but make sure the user come back to same view when leaving shopfloor and coming back via breadcrumbs.

task: [4629641](https://www.odoo.com/odoo/project/966/tasks/4629641)

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

> [!Note]
> This PR unreverts fc6b9ed22728 with a minor modification to ensure one `res.currency` record to compare amounts.

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: - 0.75 for quantity ≥ 0 - 0.50 for quantity ≥ 1000
   - Pricelist B with a -10% discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since e1b22257a714, `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

…order dropship

**Problem:**
when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values

**Steps to reproduce:**
- create a new product, with dropship and buy routes
- in the purchase tab select "on ordered quantities"
- add a vendor with a price of 10
- create a new quotation for a quantity of 10
- confirm and confirm the purchase order
- click on "create bill" and confirm it
- go back to the PO and click on the "dropship" smart button
- change the quantity to 5, validate and create backorder
- go back to the PO, click on the "dropship" smart button and select the picking of the backorder (with status ready)
- validate
- click on the "valuation smart" button

**Current behavior:**
the svl created for the backorder have a value of 100 and -100

**Expected behavior:**
it should be 50 and -50

**Cause of the issue:**
inside _get_dropshipped_svl_vals
_get_price_unit is called
https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/stock_account/models/stock_move.py#L219 because we created a bill and it's a backorder
line.qty_invoiced is higher than received_qty and this condition is true
https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L51 but because it's a dropship there is as much positive svl as negative svl linked to the move so receipt value is null https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L56-L63 and remaining value will be 100 instead of 50 (receipt value should have been 50)
https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L80

**fix**
the negative svl from the dropshipped move should not
impact receipt value


opw-4888827

Forward-Port-Of: odoo/odoo#216899

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/7ad0e33f4 [REL] 18.0.42 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/95353174b [FIX] menu: Fix menu item alignment [Task: 5028721](https://www.odoo.com/odoo/2328/tasks/5028721)
https://github.com/odoo/o-spreadsheet/commit/c3b56522c [FIX] Figure: icon of the menu item is not vertically aligned [Task: 4992687](https://www.odoo.com/odoo/2328/tasks/4992687)
https://github.com/odoo/o-spreadsheet/commit/313784f22 [FIX] clipboard: fix copy-paste from Excel [Task: 4730469](https://www.odoo.com/odoo/2328/tasks/4730469)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

### Issue
When receiving vendor bills that include bank details, if the partner has archived bank accounts, Odoo may attempt to update them. This leads to a duplicate key violation on `res_partner_bank` when the same account number already exists for the partner.

#### Affected versions
16.0 and later

#### Error example
```bash
2025-07-08 13:36:52,942 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Routing mail from "Client Name" <erp@odoo.com> to "M7- Odoo V17" <purchases@test.odoo.com>,purchases@test.odoo.com with Message-Id <*****.****.*****-****-*****-****.****@******>: direct alias match: ('account.move', 0, {'company_id': 1, 'move_type': 'in_invoice', 'journal_id': 10}, 1, mail.alias(6,))
2025-07-08 13:36:52,946 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Primary email missing on account.move
2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.sql_db: bad query: UPDATE "res_partner_bank" SET "acc_holder_name" = 'M7 GROUP INC.', "company_id" = NULL, "has_iban_warning" = false, "has_money_transfer_warning" = false, "sanitized_acc_number" = '1234567', "write_date" = '2025-07-08T13:36:52.897826'::timestamp, "write_uid" = 1 WHERE id IN (63)
ERROR: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.

2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.addons.account.models.account_move: Error importing attachment 'factur-x.xml' as invoice (decoder=_import_invoice_ubl_cii)
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 3219, in _extend_with_attachments
    with self.env.cr.savepoint():
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 85, in __exit__
    self.close(rollback=exc_type is not None)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in close
    self._close(rollback)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 113, in _close
    self._cr.flush()
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 137, in flush
    self.transaction.flush()
  File "/home/odoo/src/odoo/odoo/api.py", line 879, in flush
    env_to_flush.flush_all()
  File "/home/odoo/src/odoo/odoo/api.py", line 739, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/odoo/models.py", line 6362, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/odoo/models.py", line 6464, in _flush
    model.browse(ids)._write(vals)
  File "/home/odoo/src/odoo/odoo/models.py", line 4548, in _write
    cr.execute(SQL(
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#224071
Forward-Port-Of: odoo/odoo#223873

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: - 0.75 for quantity ≥ 0 - 0.50 for quantity ≥ 1000
   - Pricelist B with a -10% discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since PR (https://github.com/odoo/odoo/pull/213912), `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

Issue
-----
The problem is when a subcontracted product has a component tracked by lots. Creating a receipt for the subcontractor, marking it as Todo then changing the quantity leads to the reception being impossible to validate because the lots for the components cannot be set from the move.

Steps to reproduce
-----
- Create a product (Comp1)
    - Tracked by lots
- Create a product (Prod1)
    - Add a BoM - Subcontracted - Flexible consumption - Set Comp1 as consumable
- Create a receipt for 2 Prod1
- Mark as Todo
- Set Quantity to 3
- Save
- Try to validate the receipt

Situation
-----
Before changing the quantity, the user has 2 buttons ("Record components" and the move's hamburger) which open the "Subcontract" wizard. This wizard is where they can set a lot/serial for the products.

When they change the quantity of the move, the inverse method of quantity is called

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/stock/models/stock_move.py#L170-L171

This method is overridden in the mrp_subcontracting module

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L75

The part that's important to our use case is

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L81-L82

Recording components leads us to create a backorder production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/mrp_production.py#L90-L91

In our specific use case, this is problematic because the subcontract wizard loads the form of the last production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L245

The user has no way to access the previous production which lacks lot/serial (other than opening the MO itself). Obviously, we don't want to mess with this flow, but there are 2 things we can do:

1. Avoiding weird cases such as this one by forcing the user to change the quantity through the appropriate wizard
2. Providing a link to the mrp.production once some production has been recorded

For the first point, the stock.move model already has a field we can use

https://github.com/odoo/odoo/blob/8c8449f51d5e327ccd2e4bb7c3c4868d51c6d619/addons/stock/models/stock_move.py#L180

We can just override the compute to fit our use case.

For the second point, there is already a button for this. The problem is that its display condition was changed in 9ca1064 to only show once the move is picked. This fix was a bit of an over correction because we also want to show the button for unpicked moves for which a production has been recorded.

-----
Ticket:
opw-4751896

Due to an issue with the `CameraInterface`, the same identifier would be chosen for any connected camera (`camera-2`), meaning only one camera could be used at once.

To fix this, the `camera.id` property is used as the identifier instead. The `libcamera` documentation says the following:

> The camera ID is a free-form string that identifies a camera in the
> system. IDs are guaranteed to be unique and stable: the same camera,
> when connected to the system in the same way
> (e.g. in the same USB port), will have the same ID across both
> unplug/replug and system reboots.

However, we will also still return the last camera with the `camera-2` identifier, so that existing device configurations in the backend don't get lost. In master we will remove this legacy identifier. You can see the legacy camera with the others in the list below:

<img width="801" height="385" alt="image" src="https://github.com/user-attachments/assets/6f3a6408-bcb4-46b0-980e-b5a8881f6df0" />


In addition, another small fix was made to the `CameraDriver` to ensure a string is sent rather than raw bytes, this prevents a traceback when communicating over the websocket.

task-4792552

Forward-Port-Of: odoo/enterprise#93076