Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule.

Steps to replicate:
- Install `accountant` with demo, turn on `Analytic Accounting` from settings.
- Open `Accounting > Review > Depreciation Schedule`.
- Click `Analytic` > Add a `Plan`.

Error:
```
psycopg2.errors.UndefinedFunction: operator does not exist: text = record
LINE 12:             WHERE key IN (('7', '16', '8', '15', '6', '9', '...
                               ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

Cause:
- At line [1], we pass a tuple of `analytic_account_ids`, which is then wrapped again in parentheses at line [2].

- This results in the IDs being enclosed in double parentheses, e.g. `(('7', '16', '8', '15', '6'))`.

- When the `IN` clause is used with this double-parenthesized tuple, PostgreSQL treats it as a list containing a single record. It then tries to compare `key` (a text value) with that record `('7', '16', '8', '15', '6')`, effectively resulting in a `text = record` comparison, which is invalid and causes error.

Solution:
- Removed the extra parentheses from the query.

[1]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L124

[2]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L121

sentry-7423121981

Forward-Port-Of: odoo/enterprise#114334

### 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

### Issue:
Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2
https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf

Importing such files raises an error:
`Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.`

### Cause:
The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent
https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698

The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error

### Steps to reproduce:
- Install `l10n_be_coda` and switch to the `BE company`
- Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data)
Before the fix, the error is trigger

opw-6071761

Forward-Port-Of: odoo/enterprise#113904

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 before this commit:
When sending a payment reminder email for a subscription using the email composer, the template  was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing.

### Steps to reproduce the issue:
1. Install subscription and go to that app
2. Open one subscription
3. Send message > Load template: "Subscription: Payment Reminder"
4. Sentence is incomplete: missing end date of the subscription

### Cause of the issue:
The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template.

### Reason to introduce the fix:
The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer.

opw-6031613

Forward-Port-Of: odoo/enterprise#114839
Forward-Port-Of: odoo/enterprise#111801

Issue:
---
Canonical address is not correctly calculated in non-default lang.

Steps to reproduce:
1- Create a website with 2 lang: en, fr
2- Create a product with a website category.
3- Navigate to the shop in fr.
4- Open the category, then open the product.
5- Open console, and search for canonical.

As you see, in the second language, the canonical address includes the category address which is wrong.
If you visit in the default lang, the canonical correctly refers to the url without category.

Cause:
---
This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself.

opw-6086206

Forward-Port-Of: odoo/odoo#258834

Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee.

It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have:
```
+--------------+
| Shift1 User1 |
+--------------+
```
Add another shift (Shift 2) with User2.
We'll have:
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User1 |
+--------------+
```
instead of
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User2 |
+--------------+
```

Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value.

This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by
```html
<span>Employee</span><span class="..">(Department)</span>
```
in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it,
```xml
<span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/>
```
since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change.
Therefore, whenever a component's value changes
(in our case, Shift1 becomes Shift2), it is never updated.

In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution.

To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render.

opw-6128168

Forward-Port-Of: odoo/enterprise#115160
Forward-Port-Of: odoo/enterprise#115061

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
The `_compute_template_id` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96


Solution:
-----------
- Update `_compute_template_id` to ensure only active templates are
  automatically assigned.


opw-5974244




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

Forward-Port-Of: odoo/odoo#257580
Forward-Port-Of: odoo/odoo#251186

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/45f9930d5a [REL] 19.2.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a0c7941d4e [FIX] chart: figure sometime still exist after chart deletion [Task: 6107235](https://www.odoo.com/odoo/2328/tasks/6107235)
https://github.com/odoo/o-spreadsheet/commit/bc9fcef122 [FIX] package: saas-19.2 is no longer the latest stable [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account.

When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied.

On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to
 any journal item.

To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines.

opw-6107329

Forward-Port-Of: odoo/enterprise#114863

# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)

# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y

Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026

# The problem
The "Approved Time Off" and "Difference" values are wrong.

With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.

# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave

Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs

The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)

The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`)  that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)

# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").

Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)

opw-6082422

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

Forward-Port-Of: odoo/odoo#258963

When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language.

### Steps to reproduce

1. Install the "Surveys" module and activate a second language (e.g., Dutch).
2. Create a survey and ensure its invitation template has translations for both languages.
3. Create two contacts: one with English as their language and another with Dutch.
4. On the survey, click "Share" and add both contacts as recipients.
5. Send the invitations.
6. The contact with Dutch preferred language receives the email in English.

### Cause

By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one.

opw-5868581

Forward-Port-Of: odoo/odoo#259967
Forward-Port-Of: odoo/odoo#246778

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/odoo#257720

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/enterprise#114699
Forward-Port-Of: odoo/enterprise#113047

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Forward-Port-Of: odoo/enterprise#106464

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/odoo#261206
Forward-Port-Of: odoo/odoo#257539

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/enterprise#115027
Forward-Port-Of: odoo/enterprise#114786

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

Forward-Port-Of: odoo/enterprise#113926