### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses:
**Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client incorrectly retains the  `active_id` and `active_model` of the alias in the context.

**Solution:** We updated the `action_view_ticket` method in `helpdesk.team` to explicitly inject the correct `active_model` and `active_id` into  the context before calling `_for_xml_id`. This overwrites the polluted Alias data before the window action is evaluated.

### Current behavior before PR:
Clicking the "Tickets" smart button passes the old alias context into the action. This bad data flows into the ticket view, which attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message, resulting in a `MissingError`.

### Desired behavior after PR: 
The Python action sanitizes the context at the source, ensuring that the XML action and subsequent view evaluations receive the correct Helpdesk Team ID. Ultimately, the view will load normally without crashing.

opw-6395638

Forward-Port-Of: odoo/enterprise#129901
Forward-Port-Of: odoo/enterprise#125232

In the bank reconciliation widget, a reconciled transaction
matched with a bill and a loss exchange entry no longer displays
the bill reference next to the reconciled line.

Steps to reproduce:

- Have company currency USD and foreign currency EUR
- Create a vendor bill in foreign currency (100 EUR, rate 1 USD = 1 EUR)
- Create a bank transaction in the foreign currency for less than the
  bill total, at a rate making the amount higher in company currency
  (90 EUR, 108 USD at 1 EUR = 1.2 USD)
- Open the bank reconciliation widget, reconcile transaction and bill
- Unfold the reconciled transaction

Issue:

A bill reference is missing

Analysis:

The exchange difference line is reconciled with the transaction line.
Being reconciled with two lines (bill and exch), the widget relies
on `*_reconciled_lines_excluding_exchange_diff` to show the fields.
However, `count_reconciled_lines_excluding_exchange_diff`
has been defined as boolean instead of int, faulting the comparison.

opw-6479015

Forward-Port-Of: odoo/odoo#283855

Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
    - Routes: MTO + Buy
    - Tracking: By Unique Serial Number
    
- Create a Finished product:
    - Route: Manufacture
    - Tracking: By Unique Serial Number
    - BoM:
        - component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All

Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.

`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()` 
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy 
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).

At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()` 
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).

only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.

Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.

opw-6421531

Forward-Port-Of: odoo/odoo#281258

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

Forward-Port-Of: odoo/enterprise#129841
Forward-Port-Of: odoo/enterprise#126661

Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the write:

    [verifySteps] expected the following steps
    > Expected: [
      "web_save",
    ]
    > Received: []

This happens because a tap held longer than `LONG_TAP_DELAY` counts as a long press, and `_pointerUp` then dispatches no click at all. That delay spans the synthetic pointerdown and pointerup of a single `click()`, so the work a listener does during the press counts towards that delay: tapping save blurs the html field, which converts the whole editor content to inline styles, and under the load of a runbot build that conversion alone takes longer than the delay.

One solution could have been to raise `LONG_TAP_DELAY`, but a listener slower than the new value suppresses the click again.

This commit counts a tap as long only when the test releases the pointer itself, with `pointerUp`, so the work a listener does during a `click()` no longer suppresses the click.

https://runbot.odoo.com/odoo/error/946581

Forward-Port-Of: odoo/odoo#285640
Forward-Port-Of: odoo/odoo#284971

Since https://github.com/odoo/enterprise/pull/97488, the images are shared across spreadsheets and the attachments are no longer related to a specific record. Due to the management of the IrAttachment access rights, it means that those attachments are not accessible by anyone by default and we rely on the access_token to display them in the webclient.

However, the method that builds the final xlsx file fetches the images from the server and did not use the access token, meaning that it could never access the attachment. Such situation raised a UserError that was caught by the webclient.

How to reproduce:
- As admin, create a spreadsheet and insert an image inside of it
- try to download the spreadsheet as an xlsx file

counterpart of https://github.com/odoo/enterprise/pull/126384

Task-6432724

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Problem:
In Calendar, dragging a slot opens the quick create dialog. Typing a
subject and clicking the expand button in the dialog header creates the
event, but the form that opens is empty, and saving it creates a second
event for the same slot.

Cause:
`FormViewDialog` stores the id of the record it saved in `currentResId`,
which `onExpand` passes as `res_id`. `saveRecord` sets it only in the
branch that runs when no `onRecordSave` prop is given.
`AttendeeCalendarController` passes one since 30478fe855cd
(odoo/odoo#239435), so `currentResId` stays false and the action opens a
new record.

Solution:
Set `currentResId` in the shared branch of `saveRecord`. It is private to
`FormViewDialog`, so a consumer passing `onRecordSave` cannot set it.

Steps to reproduce:
- Open Calendar.
- Drag a slot in the week view to open the quick create dialog.
- Type a meeting subject.
- Click the expand button in the dialog header.
- Observe that the form opens on a new record while the event is created.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6476930)

opw-6476930

### Steps to reproduce:

- Insert a bullet list
- Inside of the list, insert a table
- Write before and/or after the table (in the same list item)
- Press enter before and/or after the inserted text
- Notice that the bullet is not split like in a normal list

### Root Cause:

- On Enter, list plugin checked whether the list item contained unsplittable element. Since the table was inside the list item, it always treated the list item as unsplittable, even when the cursor was outside the table. As a result, the list item could never be split.

### Solution:

- Instead of checking the whole list item, walk up from the split target to the list item and look for an unsplittable element along the way. This allows the list item to split normally when the cursor is outside the unsplittable.
- Also fixed the outdent check (from commit [1](https://github.com/odoo/odoo/commit/59dc5393bdf79953eb85ccdc292b0b6dc3b59304)) which only checked if the cursor's block was empty. For example, in a list item like: `<li><p>ab</p><table>...</table><p>[]<br></p></li>` pressing Enter in the empty `<p>` would outdent the entire list item (including "ab" and the table) out of the list. Now also verify that list item has no real content before outdenting.

task-6449843

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

Forward-Port-Of: odoo/odoo#280903

### Steps to reproduce: 

- Create a subcontracted product P1
- Create a storable product P2
- Buy 5 units of both products from your subcontractor
- On the receipt set both moves quantity to 2 Units
- Validate the receipt and create a backorder
#### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2.

### Cause of the issue:

Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO: 
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91
However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164
This is problematic since picking a move line will also pick the move:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267
And only picked moves are considered to be processed at picking validation.

### Note:

The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549
However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made  hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b

The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding  a picked move line on a subcontracted move will still pick that move).

Enterprise: https://github.com/odoo/enterprise/pull/123884

opw-6330584

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

Forward-Port-Of: odoo/odoo#283927
Forward-Port-Of: odoo/odoo#275304

Steps to reproduce:
===============
- Install `maintenance` module
- Set your user's timezone to Pacific/Auckland (UTC+12/+13).
- Go to Maintenance > Maintenance Requests > New.
- Set the Scheduled Date to tomorrow morning (e.g. 8:00 am).
- Save and check the auto-generated activity in the chatter.

Issue:
====
The activity generated for the maintenance request's Scheduled Date is
created with a deadline of Today instead of Tomorrow, even though the
Scheduled Date was explicitly set to Tomorrow.

Cause:
=====
`schedule_date` is a `Datetime` field, always stored in UTC. In
`MaintenanceRequest.activity_update()`, the deadline for the activity
(a `Date` field) was computed with:
```py
    fields.Datetime.from_string(request.schedule_date).date()
```
`from_string()` only parses the stored value; it does not convert it
to any timezone. Calling `.date()` on it therefore truncates the raw
UTC datetime directly, ignoring the timezone of the user who picked
the date.

For a user ahead of UTC by a large enough offset (e.g. Pacific/Auckland,
UTC+12/+13), picking "Tomorrow 8:00 am" in their local timezone can
resolve to a UTC instant that still falls on Today's date (Tomorrow
8:00 local minus 13 hours lands at 19:00 UTC on Today). Truncating
that UTC value straight to a date silently shifts the deadline back
by one full day versus what the user selected.

Fix:
===
The deadline is now computed from the schedule date after converting
it to the record's (user's) timezone, using
`fields.Datetime.context_timestamp()`, instead of truncating the raw
UTC value. This fixes the reported issue for any user whose timezone
offset makes the truncation land on the wrong side of midnight UTC.

---

Note - automatic activity creation is remove from this [commit](https://github.com/odoo/odoo/commit/ab63e9709d8ea790a8a72a0a86b8bccc478c02d5) in saas-19.2

---

opw-6363868



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

Forward-Port-Of: odoo/odoo#275330

Steps to reproduce
------------------
1. Open a restaurant PoS with a preparation display.
2. Add a product, put the internal note "A" on the line, press Send.
3. Change the note from "A" to "B", then open the note again and click "discard", that will clear it.
4. Press Send.

-> The line is fully cancelled on the preparation display and the same quantity is sent again as a new order.

Expected Behavour
-----------------
The existing line should be updated in-place instead of cancelling and re-creating a new one.

Why it's happening
------------------
In `_process_preparation_changes` we calculate a key for every line and the `note` is inside this key.

For the order lines we take `line.note or "[]"`, but for the note history we take `note['new'] or ''`, in that case, the keys don't match, so we cancel the current one and create a new line!!

The fix
-------
We use `"[]"` now, in many places (for completness), a follow up of 484ef2e8b2b.

opw-6467346

Forward-Port-Of: odoo/enterprise#128601

Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one:

    odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser:
    Error received after termination: [MEMINFO] tests done (after GC)
    - used: 220535896 - total: 341990868 - limit: 4395630592

Note that the figures themselves are fine (220MB used of a 4.4GB limit): the error is not about memory, only about when the line is logged.

This happens because the runner logs that line after `stop()`, and `stop()` is what reports the suite result: the server settles the test on that report and kills the browser. The final major GC outlasts the report. A passing build escapes because the browser dies within milliseconds; a failing one stays up for the screenshot, long enough for the GC to finish and the line to land after termination.

This commit fixes the issue by moving `stop()` after the final cleanups and their memory log: the [MEMINFO] line is still logged, but before the result report, while the server still waits on the browser.

https://runbot.odoo.com/odoo/error/229655

Forward-Port-Of: odoo/odoo#284957

Steps to reproduce:
- Restaurant config with two POS devices on the same session
- Device A: open a table, add two products, press Order (the order is synced as a draft, its lines get server ids)
- Device A: remove both lines, without syncing
- Device B: touch the same order, so device A re-reads it from the server through the synchronisation websocket
- Device A: pay and validate the order

Issue:
The order is saved as paid, with its total and its payment, but without any orderline. The lines are deleted on the server: odoo.models.unlink: deleted pos.order.line records with IDs: [...]

Cause:
Removing an orderline queues an unlink command in
models.commands['pos.order'].unlink['lines_<order id>'] (delete_ in related_models.js). That command is only discarded by clearCommands(), which syncAllOrders() calls after a successful sync, so it stays pending in between.

Any read of the order in that window puts the line back: a deleted record counts as missing in missingRecursive(), so it is fetched again and loadData() re-creates it with its server id.

serialize() then emits both the update of the live line and the still pending unlink, and sync_from_ui writes
lines: [[1, id, {...}], [3, id]]. The ORM applies commands in order, and pos.order.line.order_id is ondelete='cascade', so Command.UNLINK deletes the line right after writing it.

Fix:
Skip a removal command when the record is still linked to the parent at serialization time. A record cannot be both linked and removed in the same payload, so the pending command is stale and dropping it keeps the local state. Genuine removals, where the record is no longer linked, are still sent.

opw-6401146

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

Forward-Port-Of: odoo/odoo#285427
Forward-Port-Of: odoo/odoo#284695

### Issue:
A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version

### Cause:
`_get_version` on `hr.employee` falls back to `versions[0]` when no version matches the given date
But if the employee has no versions at all, `versions` is empty and `versions[0]` raises an `IndexError`

### Steps to reproduce:
-  Create a database with `hr_attendance` installed in 18.0
- Upgrade to 19.0

Before the fix, a warning is logged during the upgrade

### Notes:
An employee without any version is a transient state during upgrade
`hr/saas~18.4.1.1/end-migrate.py` backfills a version for every employee still missing one (`current_version_id IS NULL`) once the whole upgrade chain is done
Since it only runs at the very end, an employee can still be found without a version by earlier steps (e.g. modules reloading their demo data), which is when this warning was logged
Confirmed on an upgraded RunBot database that employees without a version before the upgrade do end up with one once fully completed

runbot-241187

Forward-Port-Of: odoo/odoo#284467

Steps to produce:
---
- Create a company with `Argentina` as the country.
- Switch to the newly created company.
- Create a new website for the `Argentina company`.
- Create a pricelist with a `23%` discount on the sales price for all products.
- Create a new product, set the sale price to 100, remove all tax, and publish.
- Go to the website and switch to the newly created Argentina company website.
- Go to the Shop page and open the product.

Issue:
---
- The tax-excluded price (`Precio s/Imp. Nac.`) displayed on the shop catalog card differs from the tax-excluded price displayed on the product detail page.

Root cause:
---
- In `_get_additionnal_combination_info`, [1] returns the unit price with the pricelist discount already applied. However, when `combination_info['has_discounted_price']` [2] is `True`, the method applies the discount again manually, resulting in the pricelist discount being applied twice on the product detail page.

Solution:
---
- Remove the redundant discount calculation block. This ensures that the tax-excluded price displayed on the product detail page matches the price shown on the shop catalog card.

[1]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L61-L62
[2]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L71-L74

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

Forward-Port-Of: odoo/odoo#283761

**Step to reproduce :**

1. Create Product A and enable lot tracking for it.
2. Create a Kit product and add Product A as one of its components.
3. Go to PoS and create orders using:
  - Product A
  - The Kit product
  - A combination of Product A and the Kit product
4. Create three different orders with these combinations.
5. Try to close the PoS session.

**Issue :**

An error occurs when attempting to close the PoS session.

The issue is in the pos_mrp module, specifically in the _get_lot_line_qty method. When accessing the following line:

`lines_data[move.bom_line_id.bom_id.product_tmpl_id.product_variant_id.id]['order_lines'].qty`

we expect order_lines to contain a single record. However, in this scenario, multiple order lines can be returned for the same product. As a result, accessing .qty directly on order_lines raises a singleton error.

**Solution :**

With this fix, we first retrieve the quantity from each order line and thensum the quantities together.

This ensures that multiple matching order lines are handled correctly and prevents the singleton error when closing the PoS session.

opw-6442765

Forward-Port-Of: odoo/odoo#284746
Forward-Port-Of: odoo/odoo#281622

**Problem:**
Opening a Project Update activity from the activity menu (the clock icon in the systray) lists every project update of every user, instead of the ones carrying the current user's activities.

**Steps to reproduce:**
1. Schedule an overdue activity on a project update
2. Have a colleague create another project update with no activity
3. Click the clock icon in the systray
4. Under "Project Update", click the "Late" count

**Current behavior:**
The list opens unfiltered and shows all project updates, including the ones of other users and the ones carrying no activity at all.

**Expected behavior:**
The list shows only the updates carrying the user's own activities, restricted to the bucket that was clicked.

**Cause of the issue:**
The activity menu never builds a "my activities" domain. `openActivityGroup` in `mail/static/src/core/web/activity_menu.js` narrows the generic act_window it opens purely through context keys — `search_default_filter_activities_my` plus `search_default_activities_overdue` / `_today` / `_upcoming_all` — and the only domain it forwards comes from `_get_activity_groups`, which is limited to `[('active', 'in', [True, False])]`. A `search_default_<name>` key is resolved against a filter of that name in the model's search view, and is silently dropped when no such filter exists. `project.update`'s search view never declared them, so every key the menu sends is discarded and the action opens on an empty domain.

**Fix:**
`project.project` and `project.task` — the addon's two other `mail.activity.mixin` models — already declare this block of invisible activity filters, as does every other model reachable from the activity menu. Declaring them on `project.update` is what makes the menu's context keys resolvable, and keeps the model consistent with the rest of the codebase instead of special-casing `project.update` on the client side.

opw-6416397

Forward-Port-Of: odoo/odoo#281511

Steps to reproduce:
-------------------
1. Install sale_timesheet.
2. Create a service product with:
   - Invoicing Policy: Prepaid/Fixed Price
   - Create on Order: Project & Task
3. Create a sales order with this product.
4. Open the generated project > dashboard and verify that "To Invoice" shows $1.
5. Create a project update and observe that "To Invoice" also shows $1.
6. Return to the sales order, create and post the invoice.
7. Open the project dashboard again and verify that "To Invoice" is now $0.
8. Create another project update.

Issue:
------
The project update margin still displays $1 under "To Invoice" even though the sales order has already been fully invoiced.

Cause:
------
The project update template displays the aggregated profitability totals (`profitability['total']['revenues']` and `profitability['total']['costs']`) instead of the dedicated `to_bill_to_invoice` and `billed_invoiced` values, causing stale "to invoice" amounts to persist after invoicing.

Solution:
---------
Use the `to_bill_to_invoice` and `billed_invoiced` values when rendering the project update profitability report.

opw-6323869



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

Forward-Port-Of: odoo/odoo#278646
Forward-Port-Of: odoo/odoo#273605

**Description of the issue/feature this PR addresses:**

`weeknumber` takes a `first_week_day` override, documented as `(0 = Monday, ..., 6 = Sunday). If None, derived from the locale.`, but tests it with `if not first_week_day`, so Monday (`0`) is discarded and the locale's own day is used.

`resource` passes `int(get_lang(self.env).week_start) - 1`, which is exactly `0` for Monday, at three call sites. #259600 added the parameter for the opposite case, a Monday locale with a Sunday-start user, and that direction works; this one never has.

**Current behavior before PR:**

With `en_US` (first day Sunday) and week start set to Monday, `resource_resource.py:299` builds `week_start_date` from Monday while `:303` buckets by Sunday. Monday 2026-08-24 to Sunday 2026-08-30 comes back as W35 for six days and W36 for the Sunday, so one week's hours are split across two buckets and the `hours_per_week` cap lands on the wrong days.

**Desired behavior after PR is merged:**

The override is honoured and those seven days are all W35.

I checked this with a partition property: every day of a `first_week_day`-aligned week must share one `(year, week)`. Over 9 locales x 7 values of `first_week_day` x 12 years, 275940 combinations, 5 locales failed and every failure was in the `first_week_day=0` bucket. After the change there are none.

I also diffed every output before and after, 315360 combinations of locale, `first_week_day` and date: 4460 rows change, all of them `first_week_day=0` on a non-Monday locale. `None` and values 1 to 6 are byte identical, so the change is contained to the broken case.

Targeting 19.0 because that is the oldest branch carrying the parameter; 17.0 and 18.0 do not have it.

AI-assisted: I used Claude to sweep the parameter space and write the tests.

Forward-Port-Of: odoo/odoo#285508