Fix quadratic performance on long SLA durations

[sifex]

Summary

Fixes the performance problem calculating SLA durations across more than a month when pauses or holidays are involved. No, this was not fixed by the earlier work — it's new in this PR.

Stacked on #20 (which is stacked on #16) — retargets to main once those merge.

Root cause

The daily loop in SLA::calculate() ran against the entire subject duration every day:

• For every day, every coverage period was diffed against all pause periods of the whole duration via $period->diff(...$pause_periods) — spatie's subtractAll/overlapAll does an O(n×m) cross-product (120+ variadic args, 128-param signature)
• The pause period array was rebuilt for every day × every coverage period
• The dedup reduce ($p->diff(...$carry)) was O(periods²) per day over the full-range period list
• The final interval combine cascaded an ever-growing interval across all days

Fix (four commits)

1. Day-clipping + forward-only sweep cursors: SLA periods and pause periods (sorted once) are clipped to the current day via cursors that only move forward — O(N×P) and O(N×periods²) → O(N+P)
2. Integer interval arithmetic: coverage dedup and pause subtraction are pure timestamp math (ps-1/pe+1 boundaries reproduce spatie's closed-interval semantics exactly — all boundary tests unchanged)
3. Sweep optimization for the same pattern applied to the remaining filters
4. No CarbonPeriod objects in the hot path: AgendaInterface::toPeriods now returns start/end Carbon pairs instead of CarbonPeriod[] (measured ~28µs per CarbonPeriod vs ~0.1µs per pair — 144ms of a 305ms 10-year calc was just constructing them). The daily loop iterates the day period directly with integer bounds (+86400 reproduces the old addHours(24) semantics exactly), and the valid_from parse is precomputed once per call. BC note: direct toPeriods() consumers now receive array{0: CarbonInterface, 1: CarbonInterface} pairs.

Results (weekday schedule, 09:00–17:00)

Scenario	Original	After commits 1–3	After commit 4
120 pauses, 30 days	1061 ms	11 ms	7 ms
120 pauses, 90 days	3098 ms	14 ms	8 ms
120 pauses, 365 days	OOM (at 180d)	36 ms	15 ms
365 holidays, 1 year	OOM	52 ms	27 ms
730 holidays, 2 years	OOM	103 ms	62 ms
No pauses, 5 years	1872 ms	161 ms	41 ms
No pauses, 10 years	—	305 ms	86 ms

The year-long daily-holiday case previously died with a 128MB memory error and now runs in ~27ms.

Behaviour notes

• Pause boundary semantics are byte-for-byte identical (closed-interval, verified by existing boundary tests)
• Removed the now-unused calculate_interval/combine_intervals private helpers; the collapses intervals test now asserts the same behaviour through the public API with overlapping schedule windows

Tests

Regression tests for year-long subjects: 365 daily holidays (was a memory fatal), 52 weekly pauses, unpaused year — 51 tests total, all green; PHPStan level 8 and Pint clean.