### Issue:
When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected

### Cause:
SIRET values must be exactly 14 characters long
However, spaces were not removed when generating the XML, leading to invalid values in:
`<cbc:ID schemeID="0009">` and `<cbc:CompanyID schemeID="0009">`

This issue can occur for both the company and the customer SIRET, as both rely on `company_registry`

As a result, Chorus Pro rejects the document due to invalid SIRET length

### Steps to reproduce:
- Install `l10n_fr_facturx_chorus_pro` and switch to `FR Company`
- Enable and Activate Peppol in Settings
- Go in Settings > Users & Companies > Companies and open the `FR Company`
- Add spaces in the Company ID: 968 515 7590 5808
- Create a Customer (Country: France, VAT: FR23334175221, Company ID/Siret: 123 456 7890 1234)
- In the customer's Invoicing Tab (Invoice sending: by Peppol, eInvoice format: EU Standard (Peppol Bis 3.0), France SIRET: 11000201100044)
- Create and Send an invoice via Peppol (Your Customer, any line with a tax)
- Open the XML
- Check the IDs and CompanyIDs in the document Before the fix, there is missing spaces

opw-6047840

Forward-Port-Of: odoo/odoo#260578

When a menu item URL contains a space and has no leading slash (e.g.,
"some url"), creating a page from its 404 screen does not link the menu
to the newly created page. The menu keeps pointing to a 404.


**Steps to reproduce**:
1. Create a menu item with a URL containing spaces and no leading slash
   (e.g., "some url").
2. Click the menu item -> a 404 page is displayed (expected).
3. Click "Create Page" -> the page is created and saved.
4. Click the menu item again -> it still returns a 404 (unexpected).


**Issue**:
During page creation, the path is slugified (e.g., "some url" ->
"/some-url"). The controller then tries to link the menu to the new page
by setting `page_id`. However, `pagenew()` only searches for menu URLs
with a leading slash, so a menu saved as "some url" is not found when
searching for "/some url". As a result, `page_id` is never set, and
`_clean_url()` keeps resolving the menu to "/some url" instead of the
page's actual URL "/some-url".

Menus without spaces (e.g., "mypage") have the same issue where
`page_id` is not set, but since `_clean_url()` prepends "/" and renders
"/mypage", which matches the new page URL, the menu still resolves
correctly.


**Fix**:
Match both URL formats (with and without leading slash) when linking a
menu to a newly created page.

Additionally, a warning is now shown in the menu editor when a URL
contains spaces, since spaces are slugified during page creation,
which could cause confusion. (Note: this is only a warning - URLs with
spaces are still allowed.)

task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646)

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

Forward-Port-Of: odoo/odoo#261208
Forward-Port-Of: odoo/odoo#248967

Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document.

The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484
Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`).
As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`.

This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state.

The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios.

The most common setup where the error happens is for invoices that have 2 DIAN documents:
1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`)
2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events)

opw-6108318
opw-5931442
opw-6034035

Forward-Port-Of: odoo/enterprise#113929

Issue:
----------------------------------------
With a specific configuration it can happen that overtime lines are not deleted when regenerating them, causing crashes in `_set_real_overtime_intervals()` for example, because several records will be linked in the same interval.

Steps to reproduce:
----------------------------------------
- Have a calendar where:
	- Attendance on Sunday
	- No attendance on Monday
	- Timezone = 'America/New_York'
- Select this calendar for an employee in UTC timezone with the default overtime ruleset
- Create an attendance for this employee:
	- Start: 10AM on a Sunday
	- End: 1AM the next day, Monday
- It should have 2 overtimes, one on Sunday the other on Monday
- Go on the ruleset and click "Regenerate ovetimes"
- Go back to the attendance and notice the overtime line for Monday is duplicated
- If you go in Payroll > Work Entries > Work Entries and select the time frame to see the attendance, it will crash

Cause:
----------------------------------------
We use `_get_tz()` to get the timezone in which we want to convert the attendance start and end to, then create the domain to search for the overtimes. But `_get_tz()` returns the calendar timezone, not the resource one, which is the one used in the attendance and overtime lines dates.

When converting the start and end of the attendance to calendar tz, they both end up on Sunday. So the domain includes the whole week before the attendance but not the Monday where there is an overtime line. So only the Sunday overtime line is selected, and only this one is [unlinked](https://github.com/odoo/odoo/blob/ca8f3e6f054748e8951a2cd05ccdc2d36388e928/addons/hr_attendance/models/hr_attendance.py#L304) leaving the one on Monday, which is later recreated.

Solution:
----------------------------------------
Use `employee.tz` instead of `_get_tz()`.

opw-6067969

Forward-Port-Of: odoo/odoo#259809

Steps:
- Install ai
- Open ai chat
- Try to send a message
- Traceback

The AI chat was failing on iOS with a traceback when trying to process
the stream response.

Even though MDN suggests compatibility, Safari (WebKit) versions prior
to 26.4 do not implement the AsyncIterator protocol on ReadableStream.
This makes `for await (const chunk of response.body)` throw a TypeError
as `[Symbol.asyncIterator]` is undefined.

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

This commit replaces the async iteration with a manual reader loop
(`getReader().read()`). This is the low-level primitive supported by
all versions of Safari and ensures the stream is properly consumed and
unlocked even if the connection is interrupted.

Steps to reproduce:
1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4).
2. Send a message.
3. The response triggers a JS error.

```js
Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...')
```

opw-6054307

Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45

Steps to reproduce:
- Create a new database with only the Purchase module installed
- Enable the "Units of Measure & Packagings" option
- Create a storable product "P1" with the following vendor pricelist:
  - Vendor: Azure Interior (1 pack of 6 for $10)
- Create a purchase order:
  - Vendor: Azure Interior
  - Quantity: 3 packs of 6 of P1
- Confirm the PO
- Click the Receive button (available without the Stock module since v19.1)

Problem:
1:/
Expected behavior: qty_received = 3 (in purchase UoM: packs of 6)
Actual behavior:   qty_received = 18 (product UoM: units)

`product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6.

2:/
The parameter `invalid_targets` was not properly passed to the
translation function in the error message, causing a traceback
when trying to receive a PO in an invalid state.

opw-6080527