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

When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a trailing parasitic digit (such as 53000.0000000002 instead of 53000.0000000000).

This commit resolves the issue by backporting the formatting logic from master. The `maxDecDigits` calculation is moved outside the conditionals so it unconditionally caps precision for all numbers. Furthermore, the global significant digit ceiling is reduced from 15 to 14.

This 14-digit ceiling reserves a 1-digit buffer, allowing the newly introduced `formatFixedDecimals` utility to safely run `roundDecimals` on the float. This mathematically sanitizes the trailing corrupted digit before it is ever converted to a string.

opw-6313540

**Current behavior before PR:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed with a corrupted digit (e.g. 53000.0000000002)

**Desired behavior after PR is merged:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed without corrupted digits (e.g. 53000.000000000)

This PR is essentially a backport of https://github.com/odoo/odoo/commit/07da917f6e3319b4acde1029e77f69f1aba314b8 and https://github.com/odoo/odoo/commit/c4e7ba8d8fdfd7b0c442cf834f562ef8cedf019b for numbers.js

Forward-Port-Of: odoo/odoo#272940

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date`.
* Added tests in the enterise module as issue occurs on installing enterprise module only.

opw-6284576

Issue:
    - When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
    - This happens because the calculation is based only on the `Average Hour per Day` and doesn't take into account the `Hours per Week` set on the employee resource. It ignores the weekly limit defined in the employee's working schedule. -As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.

    Example:
    - An employee has a 32h/week contract and 8h/day.
    - If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.

Steps To reporduce:
    - Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
    - Log 5 attendances in one week with 8 worked hours each.
    - Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.

Solution:
    - Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
    - If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.

OPW-4583064

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

Forward-Port-Of: odoo/odoo#218384

**Steps to reproduce:**

- Create a product A, tracked by lots
- Create a kit product, include a component A
- Change the UoM to 0.5
- Go to the PoS, order this kit product
- Also order the component A, with a quantity of 2
- Pay for it, ask for an invoice
- Go to the created picking
- The Demand column is correctly computed and is 0.5
- The Quantity column is wrong and is 2

**Why the fix:**

When getting the data from https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L283 
we always get the component's line, as the move's product is the component, even if it used to be the kit product's move. This is because when exploding a kit's moves, it gets the kit's component as a product instead of keeping the kit product.

This was introducing a weird behavior because we took the quantity from the component line, and not from the kit line, meaning the kit would always have the same quantity as the component.

We now check if the move is actually a kit product's move, and if it is we adapt the qty to correct one by fetching the correct line's qty, and adapting it with the correct UoM.

Changing the line in itself would not work, as the kit itself is not tracked by lots, so we would not enter https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L284 
and the move line would not be correctly created.

opw-6153000

Forward-Port-Of: odoo/odoo#273775
Forward-Port-Of: odoo/odoo#262551

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

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

Forward-Port-Of: odoo/odoo#274059