### Problem

When an AI agent includes a document source whose underlying `ir.attachment`
has `res_field` set (e.g., an invoice PDF generated from a Sale Order),
triggering **Update With AI** from **Website → Site → Optimize SEO**
raises a `KeyError` in `_build_rag_context`.

### Steps to Reproduce

1. Open the **AI** app.
2. Configure the **Odoo Agent**.
3. Add a source → **Add From Documents**.
4. Select a document whose underlying `ir.attachment` has `res_field` set
   (e.g., an invoice PDF generated from a Sale Order).
5. Go to **Website → Site → Optimize SEO**.
6. Click **Update With AI**.
7. Observe the following error:

```
KeyError: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
```

[Video](https://drive.google.com/file/d/1AAg0AvC3TRQzMLhI9hWFuSarOTHzQE-b/view?usp=sharing)

### Root Cause

In `ai/models/ai_agent.py`, `_build_rag_context()` retrieves the
`ai.agent.source` records corresponding to the embeddings by searching on the
attachment checksum:

```python
agent_sources = self.env["ai.agent.source"].search([
    ("attachment_id.checksum", "in", embeddings_attachment_checksums),
    ("agent_id", "=", self.id),
])
```

This domain traverses `attachment_id.checksum`, which internally calls
`ir.attachment._search()`.

As part of the standard attachment search behavior,
`ir.attachment._search()` automatically injects a
`('res_field', '=', False)` filter unless:

- `skip_res_field_check=True` is set in the context,
- the domain explicitly references `id` or `res_field`, or
- `bypass_access` is enabled.

```python
domain = Domain(domain)
if (
    not self.env.context.get("skip_res_field_check")
    and not any(d.field_expr in ("id", "res_field") for d in domain.iter_conditions())
    and not bypass_access
):
    disable_binary_fields_attachments = True
    domain &= Domain("res_field", "=", False)
```

[Reference](https://github.com/odoo/odoo/blob/19.0/odoo/addons/base/models/ir_attachment.py#L630)

Because of this implicit filter, attachments with `res_field` set are excluded
from the search. Consequently, `agent_sources` does not contain all the sources
corresponding to the retrieved embeddings.

Later, `_build_rag_context()` builds a checksum-to-source mapping:

```python
source_map = {
    source.attachment_id.checksum: source
    for source in agent_sources
}

for embedding in similar_embeddings:
    checksum = embedding.attachment_id.checksum
    agent_source = source_map[checksum]
```

Since `source_map` is built from the incomplete `agent_sources` recordset, it is
missing entries for attachments filtered by `ir.attachment._search()`.
However, `similar_embeddings` still contains embeddings for those attachments.

As a result, the lookup:

```python
agent_source = source_map[checksum]
```

raises a `KeyError`.

### Solution

Bypass the implicit `res_field` filter when searching `ai.agent.source`:

```python
agent_sources = (
    self.env["ai.agent.source"]
    .with_context(skip_res_field_check=True)
    .search([
        ("attachment_id.checksum", "in", embeddings_attachment_checksums),
        ("agent_id", "=", self.id),
    ])
)
```

This ensures that all `ai.agent.source` records matching the requested
attachment checksums are returned, including those referencing attachments with
`res_field` set. As a result, `source_map` contains all expected entries and
`_build_rag_context()` no longer raises a `KeyError`.

opw-6379816

Forward-Port-Of: odoo/enterprise#125780

Problem:
On a flexible working schedule, a time off of a few hours (neither a full nor a half day) was treated as a full day off. The Attendance list then reported the whole day's attendance as overtime, and the Time Off gantt grayed out the entire day instead of only the leave's hours.

Steps to reproduce:
1. Give an employee a flexible working schedule (e.g. 8h/day) with an overtime ruleset based on the contract's expected hours.
2. Record a 2-hour time off, then an 8-hour attendance on the same day.
3. Observe the attendance reports 8 hours of overtime instead of 2.

Current behavior:
A partial time off makes the whole day count as extra hours.

Expected behavior:
Only the hours actually taken off reduce the day's expected hours.

Cause:
For a flexible schedule, _handle_flexible_leave_interval expands a leave to the whole day. The override already narrows full-day and half-day leaves, but any other number of hours fell through to that full-day expansion. The expanded interval is subtracted from the day's expected hours in _work_intervals_batch, so they drop to zero and every worked hour becomes overtime.

Fix:
A leave of an arbitrary number of hours should only remove the hours it actually covers, so it keeps its requested interval instead of being stretched to the whole day.

opw-6291536

Forward-Port-Of: odoo/enterprise#127257
Forward-Port-Of: odoo/enterprise#123778

Steps to reproduce:
-------------------
1. Install `l10n_mx_edi_pos` and set the company to Mexico.
2. In PoS, make an order with one product and pay it.
3. Open the order in the backend, click "Return Products" to make a refund, but don't pay it, cancel it instead.
4. From the same order, click "Return Products" again to make a second refund, and pay it normally.
5. Go to the orders list, select the main order and the paid refund (not the cancelled one), then Actions > Create Global Invoice.

-> Observation: error in the global invoice.

In the CFDI tab of the main order the line is "Send Global In Error", and hovering on it the detail says "Failed to distribute some negative lines".

Why:
----
When we make the global invoice, we remove the refunds from the order. A cancelled refund was never paid, so we should not count it. But we were counting it too. So we removed the refund amount twice in our case, one for the paid refund, and one for the cancelled one, and we end up with an order with negative amount that cannot be distributed.

The fix:
--------
We now skip the cancelled orders when we search the refunds, the same way it is done above when we collect the refunded orders.

opw-6261404

Forward-Port-Of: odoo/enterprise#127724
Forward-Port-Of: odoo/enterprise#120996

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
Original fix (see [1]) was not enough for every case. Additional issues:
- Chatter hidden on init even when its panel has `visible = true`
- State desynchronized with the view when switching menu type (kanban/list) or by previewing a document and coming back
- When using the button with an open preview, chatter shows up in the background but is not accessible (and going back discards it)
- Removing selection with an open chatter disable the related action

**Fix:**
- Disable the chatter on mobile init by default to avoid having to manually move it back
- Reset chatter on selection removal to avoid getting stuck in the menu
- Reset chatter on view switch to avoid being in the wrong state afterwards
(and revert the previous css changes)

Not a great fix (quite mobile-specific) and there might still be some edge cases.

[1] original fix: https://github.com/odoo/enterprise/commit/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52

opw-6061993

Forward-Port-Of: odoo/enterprise#121521

Steps to reproduce
---
1. Create and confirm a sale order.
2. Create a down payment invoice on it and post it: the down payment line reads "Down Payment (ref: INV/... on ...)".
3. Open that invoice and use Reverse and Create Invoice, then post the newly created draft down payment invoice.
4. Open the sale order: the down payment line has lost its reference and now reads only "Down Payment", and that empty label also carries over to the down payment section when generating the final invoice.

Issue
---
The down payment line description is built by `_get_downpayment_description`, which only produces the "Down Payment (ref: ... on ...)" label when exactly one customer invoice is linked to the down payment `sale.order.line`, guarded by `len(invoice) == 1`.

https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/sale/models/sale_order_line.py#L484-L509

Reverse and Create Invoice runs `account.move.reversal.modify_moves`, which copies the reversed invoice with `include_business_fields=True`, so the copied line keeps its `sale_line_ids` and the new draft invoice is attached to the very same down payment line as the reversed original.

https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/account/wizard/account_move_reversal.py#L142-L149

That down payment line then references two `out_invoice` moves (the reversed one and the re-issued one), so `len(invoice) == 1` is false and the label silently falls back to the bare "Down Payment", losing the reference that the final invoice's down payment section reuses. Going back to the sale order to raise a fresh down payment instead creates a new line, which keeps a single invoice and is why the slower flow is unaffected. The `len(invoice) == 1` guard was introduced in ba954604e529. Discarding the reversed invoice (`payment_state == 'reversed'`) leaves the active re-issued invoice as the single match, so its reference is shown again; when the only linked invoice is itself reversed, the fallback keeps displaying it so existing descriptions are preserved.

opw-6353384

Forward-Port-Of: odoo/odoo#277802

Steps to reproduce:
- Make sure you have 2 or more languages installed
- Install events and website app
- For the website, apply the languages you have in settings
- Make sure website default language is different from backend language
- Create an event
- Go to the event's website page through the smart button
- Switch the language of the frontend to one that is different from backend
- Translate (alter) the description for this language
- Click on the outlook icon to download the ics

Current Behavior:
The ics will contain a description based on the backend's chosen language

Expected Behavior:
The ics will contain a description based on the website's chosen language.
If there's no website, it will use the browser's language

Clarification:
The current behavior is confusing for users as they will expect the ics to match
the description of the current webpage which is dependent on the frontend's
selected language. This current behavior also contradicts the google calendar
behavior which grabs the description based on the frontend's selected language.

The endpoints for retrieving the ics file now utilize the website=True flag to
take advantage of IrHttp._match which will automatically set the context
language to be the frontend's rather than the backend language. We want
the ics file to be in the frontend language for visual consistency. Also,
send_email_reminder function does not require with context for this reason

opw-6235320

Forward-Port-Of: odoo/odoo#271968