Issue
-----
When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour.

Steps to reproduce
-----
- Enable packages
- Create a product AAA tracked by SN
	- product category removal strategy set to "Smallest number of packages"
- Create a reception for 5 units
	- Generate serials
	- Put last line in pack
- Confirm reception
- Create delivery for 2 units of AAA
	- Mark as Todo
	- Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4)
- Create a delivery for 3 units of AAA
	- Mark as Todo

> Quantity reserved is one, it only reserved SN 5

Cause
-----
The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

We end up at

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724

The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from.

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705

This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available.

This leads to `quants` in `_get_reserve_quantity` containing unavailable quants

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866

This later gets "caught" in `available_quantity`

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897

and the quants don't get reserved a second time thanks to

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914

but this also means the reservation is incomplete.

Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

and avoid the faulty logic.

Solution
-----
Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91

Our options are:
- make the field stored (not stable)
- add a search function
- filter reserved quants out of `single_item_ids`

First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss.

-----
Ticket:
opw-5972350

Forward-Port-Of: odoo/odoo#261568
Forward-Port-Of: odoo/odoo#256106

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#261935
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace

### Cause:
Before 18.4, `_postprocess_invoice_ubl_xml()` used f-strings to generate the XML content

With this formatting, the result of:
`base64.b64encode(attachment_values['raw']).decode()` was indented together with the XML block, introducing unwanted whitespace and line breaks inside `EmbeddedDocumentBinaryObject`

### Steps to reproduce:
- Install `l10n_de` and switch to the DE Company
- In Settings, enable Peppol and Activate Electronic Invoicing
- Create and confirm an Invoice (Customer: DE Company, any product line with tax)
- Send the invoice via Peppol
- Check the generated XML attachment

### Before the fix:
The XML contains formatted content such as:
```xml
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">
	content
</cbc:EmbeddedDocumentBinaryObject>
```
This formatting introduces leading/trailing whitespace and may be rejected by strict validators.

### After the fix:
The XML is generated without extra whitespace:
```xml
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">content</cbc:EmbeddedDocumentBinaryObject>
```

opw-6121616

Forward-Port-Of: odoo/odoo#262472

Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner many2one (e.g. customer/vendor on an invoice) still used the old path: calling an IAP suggestion `iap_partner_autocomplete_add_tags`

Steps to reproduce:
-------------------
* Open a customer invoice (draft).
* On Customer, search a company name and pick a Partner Autocomplete line to create a new company.
* Save the quick-create dialog.

> Observation:
The new contact still had Partner Tags populated from DnB industry data (UNSPSC), unlike contacts created or enriched from the contact form autocomplete.
(see video on ticket to avoid using more IAP credits)

Why the fix:
------------
Align `res_partner_many2one` with `field_partner_autocomplete`: do not call `iap_partner_autocomplete_add_tags`.
From task-5373200, industries from DnB must no longer be added as Partner Tags.

opw-5972360

Forward-Port-Of: odoo/odoo#260078