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

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

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

calendar.resource has a method, `_attendance_interval_batch`, that
can cause a bug if someone is trying to book an appointment with a 
staff with flexible hours.There's an elif block that you enter if the 
calendar.resource has flexible hours. In that block, we determine 
how much time is allocated for the appointment. For instance, 1 hour
 if the appointment is meant to be 1 hour long and the staff still has at
least 1 hour left to work that week. Then, a work interval gets centered
around 12 noon. 12 noon is hard-coded in. If there's one hour 
allocated for the appointment, that work interval will always be from
11:30 to 12:30, no matter what appointment time slot was selected. So,
unless by lucky coincidence, the person selected an 11:30 appointment,
they won't be able to schedule an appointment at all.

The hard coding with 12 noon was implemented 4 months ago. It's 
meant to "solve issues in various apps such as work entry generation, 
attendance overtime calculation and time off calculations." Since the 
hard coding around 12 noon serves useful purposes, I didn't remove it.
Instead, I added a flag `booking_apt=True` to signal that an
appointment is currently being booking. And I added conditional logic
so the work interval won't be centered around noon iff an appointment
is being booked.

I introduced the flag in the appointment.type method 
`is_appointment_slot_valid`. I originally tried introducing it in a 
function further up the call stack, but that lead to the flag being true
when the current process was getting all possible appointment slots,
and it broke that process. It seemed clear from 
`_is_appointment_slot_valid`'s title and docstring that its sole purpose
is to check whether an appointment being booked is at a valid time.

Solves ticket 5094795

Description of the issue/feature this PR addresses:
It solves ticket 5094795.

Current behavior before PR:
If you try to book an appointment with a staff with a flexible schedule,
and the appointment type's `work_hours_activate` field is true, you'll
get a 404 page missing error. (See ticket.)

Desired behavior after PR is merged:
You will not get a 404 page missing error anymore, and will be able
to successfully book an appointment.

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

### Steps to reproduce:

- In the setting enable lots and serial numbers
- Create a product tracked by LOT
- Create and confirm a receipt for 1 unit of that product
- Create a new lot: LOT001 from the move in the picking form
- Click Validate
#### > Invalid operation: you need to provide Lot/Serial numbers of the product

### Cause of the issue:

The set method of the `lot_ids` field of the `stock.move` model does nothing for product tracked by lots:
https://github.com/odoo/odoo/blob/7a8f9b7fe4dded4cfa140103d51b52e08149cadb/addons/stock/models/stock_move.py#L575-L579 In particular, while the lot appears on the move in the view, none of the move lines refer to it and the transfer can not be validated as indeed no lots are provided to these reservations.

### Fix:

The feature of writing `lot_ids` for lots has been introduced in https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e https://github.com/odoo/odoo/blob/1c52e2e9e8e00a19e2db00bf70d658496f9a0f29/addons/stock/models/stock_move.py#L596-L600 But this major refactoring can of course not be backported in 18.0. Therefore, it was decided put the field in readonly when its set method is inefficient.

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

**Current Behavior:**
With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.

**Expected Behavior:**
All rentals for the same SN should appear in the rental schedule.

**Steps to Reproduce:**
- Go to Rental > Configuration > Settings and enable Rental Transfers
- Create a new product that is storable, can be rented, and is tracked by unique serial number
- Receive 25 of the product with assigned serial numbers
- Create and confirm a rental order for 25 units of product
- Validate both OUT and IN transfers
- Duplicate the rental order and confirm it
- Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25

**Cause of the Issue:**
Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental.

This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule.

**Fix:**
Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times.

opw-5003247

Forward-Port-Of: odoo/enterprise#95315