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

The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot.

This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small.

### Current behavior before PR:

The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found.

This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times.

### Desired behavior after PR is merged:

The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval.

This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios.

### Benchmarks

Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board.

| Work Order Duration | Before | After |
| --- |---|---|
| 1sec | ~2.5min | <1sec |  
| 1min | ~2sec | <1sec |

### References

opw-5437256


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

When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed.

### **Steps to reproduce:**
1) Install Timesheet Grid.
2) Assign a flexible working schedule (40 hrs/week, 8 hrs/day) to an admin.
3) Enter timesheets with 8 hours per weekday for a full month (except Feb).
4) Open the timesheets grid month view.

Note: current formula correctly calculates for feb month **((40/7)** * **28) = 160**

### **Observed behavior:**
The weekly view shows correct totals, but the monthly view displays a deficit (176 h with -1:08 h), despite all working days being fully completed.

<img width="1920" height="366" alt="image" src="https://github.com/user-attachments/assets/df98c3e0-ee89-455d-86c6-7941ba0cb7a8" />


### **Expected behavior:**
The monthly view should correctly calculate the required hours i.e 176 h

<img width="1909" height="357" alt="image" src="https://github.com/user-attachments/assets/c082953a-62ad-4096-8774-76d9ff7b3b25" />


### **Root Cause:**
The method [_count_daily_working_hours](https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L82) calculated `full_time_required_hours` for a period by dividing the weekly required hours by 7 (including weekends) and multiplying by the total calendar days in the period at [1]. This gave incorrect required hours for months that have extra weekend days.

[1]- https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L115

### **Fix:**
Update the computation to divide the weekly `full_time_required_hours` by `5` (standard working days) and multiply by the actual number of weekdays in the requested period.

**Example calculation for the month March 2026:**

|  | Formula | Values | Calculation | Result |
|--------|--------|--------|--------|--------|
| Before Fix | round(full_time_required_hours / 7 * (delta.days + 1), 2) | full_time_required_hours = 40, delta.days + 1 = 31 | round(40 / 7 * 31, 2) | **177.14 h** |
| After Fix | round((full_time_required_hours / 5) * working_days_in_period, 2) | full_time_required_hours = 40, working_days_in_period = 22 | round((40 / 5) * 22, 2) | **176.00 h** | 

**opw-5966769**

1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)

To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
    edi_users._peppol_get_message_status()
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
    processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
    peppol_response = uuid_to_record[uuid]
       ^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```

task-None

Description of the issue/feature this PR addresses:

When visualizing the structure of a BOM with subcontracted components, the subcontracting cost is omitted if no supplierinfo record exists with a `min_qty` less than or equal to the requested quantity.

This leads to an inconsistent experience compared to regular components, which still show a price by selecting the closest lower `min_qty`. For subcontracted components, if the requested quantity does not match any valid `supplierinfo`, the cost line silently disappears from the report.

Current behavior before PR:

The subcontracting cost is not shown in the BOM cost structure if no `supplierinfo` matches the requested quantity (i.e., `min_qty > quantity`).

Desired behavior after PR is merged:

If no matching supplier is found for the requested quantity, the fallback logic uses any available supplierinfo (as already done in `_format_route_info`), ensuring a price is shown for subcontracted lines. This guarantees the BOM cost structure always includes the subcontracting cost, making the report complete and coherent.

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