Prevent schedule date mutation during timezone calculations

[stevebauman]

Bug

When a timezone-aware schedule calculated its next occurrence, getNextOccurrence() called setTimezone() directly on the CarbonInterface instance it received. If the caller passed a mutable Carbon instance, that call changed the caller's object in place.

That could leak the schedule's timezone back into calling code that expected its original date object to remain unchanged after asking the driver for the next run time.

Fix

The schedule driver now calls avoidMutation() before applying the schedule timezone. This preserves the existing timezone-aware calculation behavior while preventing mutable input dates from being modified.

Tests

• Added regression coverage proving a mutable UTC Carbon instance remains in UTC after a timezone-aware next occurrence calculation.
• Ran ./vendor/bin/pest.
• Ran ./vendor/bin/pint --dirty.