### Issue:

During migration of Malta taxes, the script can fail when certain tax XML IDs are missing for a company. If the XML ID does not exist, `env.ref(..., raise_if_not_found=False)` returns None. Trying to combine a recordset with None causes the migration to fail. Due to recent [commit]

### Traceback:
```py
    tax_7 |= env.ref(f'account.{company.id}_VAT_S_IN_MT_7_G', raise_if_not_found=False)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6589, in __or__
    return self.union(other)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6603, in union
    raise TypeError(f"unsupported operand types in: {self} | {arg!r}")
TypeError: unsupported operand types in: account.tax() | None
```
### 
Solution:

Use a guard check with the walrus operator (:=) to assign and validate the tax record before union.
This ensures that only existing tax records are added to the recordset, preventing the crash.

Ticket [link1](https://www.odoo.com/odoo/project.task/6159300) [link2](https://www.odoo.com/odoo/project.task/6149387)
opw-6159300 
opw-6149387

Forward-Port-Of: odoo/odoo#264327

…to hours

## Issue:
'request_hour_from' and 'request_hour_to' should be computed using the default
 calendar attendance values, but instead they display 12:00 AM, meaning their
values remain 0.0.

## Steps to Reproduce:

- Open the Time Off app.
- Configure a Time Off Type with the Duration Type (request_unit) set to Hours.
- Set this Time Off Type as the default one while creating a new Time Off.
- Create a new Time Off request.
- Observe that 'request_hour_from' and 'request_hour_to' are not computed and display 12:00 AM (0.0).

## Root Cause:
While fixing the issue related to preserving leave hours when changing Time Off Types, a regression was introduced.

Related PR: https://github.com/odoo/odoo/pull/227235

During the creation of a new Time Off with the duration type set to Hours by default, the field 'request_unit_hours' is already True. This prevents the computation of 'request_hour_from' and 'request_hour_to', resulting in both values remaining 0.0.

## Solution:
Compute 'request_hour_from' and 'request_hour_to' when their values are still 0.0 (initial Time Off creation case), and skip recomputation only when switching between Time Off Types in order to preserve manually entered hours.

Steps to reproduce : [Video](https://drive.google.com/file/d/1P2MFIj8ZxFtFxv2FlX4Zdq6P-5veTxUb/view?usp=sharing)

OPW: 6209992

Forward-Port-Of: odoo/odoo#265648
Forward-Port-Of: odoo/odoo#264707

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#265206

# How to reproduce
- Start from a fresh database
- Install the account module
- Import companies with a data file. These companies need to have a country set and the
data file needs to contain some bad data
- Click on the Test button

# The problem
An Odoo Server Error is displayed saying : "savepoint xxx does not exist", which prevents
the import or hides other potential error. More importantly, the date is imported even though it was a test run.

# Cause
Importing companies with a country will import their respective l10n modules using
`button_immediate_install()` :
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/odoo/addons/base/models/res_company.py#L319-L322
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L237

This import calls `cr.commit` :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/ir_module.py#L632-L634

The issue is that when importing a data file, we create savepoints :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/models.py#L971-L974

And if an error arise during our import, we rollback to the appropriate save point. Sadly,
commiting erases any existing save point, so a savepoint error is rased and the
data is not rolled back.

The problem stems from the fact that importing module is simply not transactionnal and
`button_immediate_install()` is not expected to be called with a savepoint. This
was already partly adressed by :
https://github.com/odoo/odoo/commit/66dcee9aa70dc72a332fde64dbc802266bbe4a5a

But it did not cover the file importing case

opw-6174983

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

Forward-Port-Of: odoo/odoo#265188