Currently, an error occurs when user editing the budget report items.

Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view):
 - Install the `Accounting` module.
 - Go to `Profit and Loss` > `Budget` and `create a budget`.
 - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line.
 - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again.
 - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more.

`TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'`

This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`.

This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained..

[1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49

[2]-
https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79

[3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72

[4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61

sentry-6883207225

Forward-Port-Of: odoo/enterprise#95090

**Steps to reproduce:**

1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.

**NOTE**
-  You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
    invoice = env['account.move'].create({
        'move_type': 'out_invoice',
        'partner_id': 10,
        'company_id': env.company.id,
        'invoice_line_ids': [(0, 0, {
            'product_id': 16,
            'quantity': 1,
            'price_unit': 100.0,
        })],
    })
    invoice.action_post()
```

 **Issue:** 

`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.

 **Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73

- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />

- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />


**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.

**opw - 5083894**

Forward-Port-Of: odoo/enterprise#95396
Forward-Port-Of: odoo/enterprise#95103

#### Steps to Reproduce
In Payroll → Employees → Salary Calculator:
1. Select an employee with a working schedule.
2. The working schedule is auto-filled in the modal.
3. Remove the working schedule.

#### Issue
A traceback occurs because the flow tries to recompute work entries with an empty calendar in the Salary Calculator.
The purpose of this PR is to make the Working Schedule field optional, with the company's schedule as default when it's empty.

#### Fix
- Always attach `salary_simulation=True` in the base `_get_version()` and propagate the context when creating a new version for the simulation employee, to avoid unnecessary work entry recomputations.
- The Working Schedule field is no longer required: it now has a placeholder and defaults to the company’s calendar when left empty.
- The "Configure Benefits" and "Copy Link" buttons are now always enabled since there's always a working schedule (company's schedule is required).

task-5063150

Forward-Port-Of: odoo/enterprise#94624

### Issue 1:

Summary:
When a user adds a comment inside a baseContainer element, the comment
beacons created during the comment insertion can be discarded during
the document normalization step.

How to reproduce:
- Open an article in Knowledge.
- Select text and change the block style from "Paragraph" to "Normal"
  using the powerbox.
- Add a comment on the selected text using the powerbox.
- Write a message in the comment thread.
- Save and reload the article.

Issue:
- The comment beacons disappears from the editor and the user can't see it
  anymore.

Resolution:
When the editor is initialized, `div` are not yet categorized as
paragraph related elements. The `comments_plugin` logic to identify valid
positions for comments beacons should take that into account and allow elements
which are candidates to be a paragraph related element.

### Issue 2:

Summary:
There was an issue where comments were not displayed when switching from a
locked article to another (read-only).

How to reproduce:
- Create two articles and add a comment on each.
- Lock both articles (so that they are effectively read-only).
- Switch from one article to the other.

Issue:
- Comments are not displayed to the user.

Resolution:
When switching between read-only articles, `KnowledgeHtmlViewer` is
not fully reloaded and continues using the same `CommentBeaconManager`
instance for the newly opened article. As a result, comment beacons
are not displayed when switching article. The simplest solution to this issue is
to re-instantiate a new `CommentBeaconManager` whenever the HTML value changes
to ensure comments are correctly displayed.

### Issue 3:

There is an issue in the logic of `computeVerticalDimensions` to display
comments. If the `top` value of a thread in the article is `0`, it will be
filtered out and not displayed because `top` was used as a boolean value.
Instead, it should properly consider `top` as a finite number to display the
comment or not.

Note:
This issue is not easily reproducible because there are few configuration where
a comment would have a top value equal to 0.

### Issue 4:

There is a crash when inserting a knowledge comment in a `/code` block:
In this previous [task], insertion in `pre` elements was filtered to prevent
non-phrasing content from being inserted (as it is invalid per the html
specification). To prevent a crash, knowledge comments will be disabled in
`<pre>` elements, as they rely on `anchor` elements for the comment position in
the article body.

[task]: 216e9eb

task-4984152

Forward-Port-Of: odoo/enterprise#95952
Forward-Port-Of: odoo/enterprise#91408

Issue:
Currently when we consolidate billing for PoS orders we receive an error because some l10n fields expect a single record and not a recordset. This can be solved by looping over the PoS orders instead and preparing the invoice values per order (this is how the sale orders handles consolidated billing) however, we run into an issue if not all PoS orders have the same l10n fields. Ideally PoS orders with different l10n fields should not be consolidated.

Purpose of this PR:
Allow the l10n fields to be reassigned for consolidated billing. The l10n fields will be added to the Create Invoice(s) wizard and those values will be used for the newly created invoice instead of the possible mixed values from the PoS orders. The values are assigned through context.

Steps to reproduce on Runbot:
install pos and l10n_mx*
create pos orders for same contact
try to create invoices with consolidated billing enabled singleton error is raised

Note:
spoke about this change with LAO
Currently the sale orders handle this error by looping over the orders, however the invoice created will have the l10n fields of the last sale order. This can lead to misinterpreting information.

opw-4802180