Harden scheduling against unbounded ranges and invalid input

[marianogoldman]

Context

Security review of the library. No injection sinks (eval/exec/unserialize/SQL/file I/O are all absent) and composer audit reports no vulnerable dependencies. The realistic risks were resource exhaustion (DoS) and weak input validation. This PR addresses all four findings from that review.

Changes

🟠 Unbounded date range → memory/CPU exhaustion

WeeklyScheduleAgenda, AgendaSlotter and DaySlotter emit one entry per day (and per slot) across the [from, to] window, so a huge range could exhaust memory. They now take an optional maxDays argument (default 366, 0 disables) and throw Puntodev\Bookables\Exceptions\DateRangeTooLargeException when the window is larger, via a shared DateRangeGuard.

🟡 Non-positive duration/step → degenerate zero-interval loops

AgendaSlotter and DaySlotter constructors now reject duration/step ≤ 0 (and negative timeAfter/timeBefore) with InvalidArgumentException.

🟡 Loose time validation

WeeklySchedule validates times strictly as a time of day (HH:MM or HH:MM:SS, 00:00–23:59), rejecting relative expressions like now / +1 day and out-of-range values like 25:00 / 14:60.

🔵 Malformed JSON

WeeklySchedule::fromJson() throws a clear Exception on malformed/non-object JSON instead of leaking a TypeError.

Tests

TDD throughout — each test was watched failing before implementing. 51 tests pass (37 existing + 14 new).

⚠️ Potentially breaking

• Times must be zero-padded (08:00, not 8:00). Matches the defaults/docs, but stricter than before.
• Ranges spanning more than maxDays (default 366) now raise instead of silently generating huge result sets. Pass maxDays: 0 to opt out.

🤖 Generated with Claude Code