Go to `/my/tasks`. The search on milestones is really slow.

Performance improvement for a portal user:

|  | Time | Query plan |
|--------|--------|--------|
| Before | ~3.6s | https://explain.dalibo.com/plan/dga21917bc86eg54 |
| After | ~60ms | https://explain.dalibo.com/plan/91b818beg2f1077f | 

For portal users, complex record rules require joining the `project` table.
Because the query includes a `limit=1`, the postgresql query planner assumes
it will find a matching row almost immediately. Hoping for a "fast exit",
it chooses to sequentially scan the `project_id` index to perform a
Merge Join. However, if it doesn't find a match early on, it ends up scanning
the entire index, resulting in a massive slowdown.

We update the `search_count` constraint from `limit=1` to `limit=80`.
By increasing the limit, we alter postgresql's cost estimation. The planner
can no longer assume a cheap "fast exit" is guaranteed, which forces it to
abandon the flawed Merge Join strategy. Instead, it correctly evaluates the
query and chooses the index on `milestone_id` to retrieve the records.

task-6373729


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

Forward-Port-Of: odoo/odoo#283239

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

Forward-Port-Of: odoo/odoo#284278
Forward-Port-Of: odoo/odoo#246015