When users refund a real-time/standard cost product purchase, cogs lines are not reversed

**Steps to reproduce**

1. Create a product category [CATEG]:
    - Costing Method: Standard
    - Inventory Valuation: Automated
    - Price Difference Account: 101403 Outstanding Payments (any account will do)
2. Create a product [PROD]
    - Type: Storable
    - Category: [CATEG]
3. Create and confirm a PO with [PROD]
4. Process the receipt
5. Create the bill
6. Issue the return and process it
7. Create the refund

**Issue**

The credit note cogs lines (price difference account and stock interim) have the same balance of the bill
However the credit note should mirror the original BILL with the opposite accounting entries.

This seems to occur because, when generating cogs lines, we take into account that the current move is a refund but then we use the move direction sign to alter the balance sign

opw-4845342

Forward-Port-Of: odoo/odoo#224873
Forward-Port-Of: odoo/odoo#221198

**Current behavior:**
Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting
to match the ensuing OUT layer with the IN layer from the
original MO.

The point being to eliminate a potential valuation imbalance for
the manufactured product (might affect cost, etc.).

**New behavior**
Don't attempt to match an unbuild valuation layer with the
original MO valuation layer. If there is some cost difference
between build time and unbuild time, make a corrective journal
entry for it.

**Issue with current behavior**
The following sequence:
1. Create Product A with average costing, real-time valuation
2. Create 2 components, avg costing, real-time val
3. Create a BoM for Product A with the components
4. Manufacture 3 units of Product A with different component
quantities (can set flexible consumption on BoM)
5. Unbuild the first manufactured unit

Results in Product A's cost not matching the expected average
cost according to the valuation layers.

**Cause of the issue:**
Unbuilding the first MO created an out move at the original
"build time" cost, but since we've built 2 additional qty, that
original cost is not the current average cost- thus the
"theoretically current" standard price of the product (sum of
layers value divided by remaining qty) is no longer the value we
see on the product form.

**Fix:**
Don't try and match the valuation layers. Aside from issues such
as the one described above, it might not actually make
functional sense to do so (e.g., FIFO isn't actually adhering to
first-in-first-out if we're preferring the original IN layer for
an unbuild valuation).

Instead we make a journal entry with any excess cost of
production (it was actually a solution proposed in the
discussion on https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 in the first place).

Additionally, now that we aren't doing this mapping, we can
revert the non-test difference of https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47, as this commit was
fixing an issue introduced by the change which added the
mapping.

opw-[4877597](https://www.odoo.com/web#id=4877597&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#222014
Forward-Port-Of: odoo/odoo#221718

Currently, an error occurs when a user attempts to reload the fiscal localization after uninstalling the `l10n_syscohada` module.

**Steps to Reproduce:**
- Install l10n_cf module(with demo).
- Switch the company to `CF Company`.
- Navigate to Invoicing settings
- Login in different device with admin rights
- In other device, uninstall l10n_syscohada module.
- Now switch back to main device  and do not reload the tab.
- Click on Reload button under Fiscal Localization.

**Error:**
`TypeError: super(type, obj): obj must be an instance or subtype of type`

**Root Cause:**
since https://github.com/odoo/odoo/pull/186635/commits/58fb2db14ce3b7ddd70ffd617d2152c836151455, the line `self = self.env()['account.chart.template']` was removed from [1] when clicking the reload button, system tries create **data** at [2] but fails because the registry has been reset.

[1]- https://github.com/odoo/odoo/blob/1dfa4cc9d259b4918424a07394938e24da8c643d/addons/account/models/chart_template.py#L183-L184

[2]- https://github.com/odoo/odoo/blob/c363014fe77d2ea706dabf8af232745d4e723267/addons/account/models/chart_template.py#L222

**Solution:**
This commit prevents the error by providing new `env` with new `registry` to handle
loading during the reload process.


Sentry-**6272559266, 6750055374**

Forward-Port-Of: odoo/odoo#216315

Currently an error occurs when signing an encrypted file with empty password.

**Steps to replicate**
* Install `Sign`
* Sign> Upload a pdf > Add following [pdf](https://drive.google.com/file/d/1M0_VzWLzv-lSZ-IlI9Zmx-M7jFGvtJJj/view?usp=sharing)>  Sign the document using `Sign now`
* Validate and send completed document

`AttributeError: 'NoneType' object has no attribute 'seek'`

**Cause:**
This occurs because [1] returns `None` to the variable `output` at [2] which in turn passes the `None` value to [3] causing the error.

Error occurs in python 3.12+, because it does not throw an exception in `_check_pdf_data_validity`.

**Solution:**
* Add a validation to prevent upload of unsupported files.

[1]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_document.py#L242-L243
[2]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_completed_document.py#L33-L34
[3]: https://github.com/odoo/odoo/blob/033c7a63bdf3d10d9d2c5084959fd34f52011bea/odoo/tools/pdf/signature.py#L51

**Sentry-6784800544,6802557168**

Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work.

After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device.

This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons:
- Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts.
- Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier.

task-5055027

Forward-Port-Of: odoo/enterprise#93593