Correct DST-aware app schedule evaluation

[hamzamerzic]

Summary

• resolve each IANA schedule in its own timezone before deciding whether it is due
• compute the following run from the local wall-clock target, including DST transitions
• keep legacy fixed-offset schedules working while avoiding stale-offset arithmetic
• cover spring-forward, fall-back, invalid timezone, and compatibility cases

Context

This is the reviewed correction discussed on #314. That PR establishes the right durable IANA identity but still evaluates future runs through the offset captured at the last execution, which is wrong across daylight-saving transitions. This branch keeps its data model and replaces only the schedule arithmetic that must be timezone-aware.

Testing

• pytest -q backend/tests/test_cron_jobs.py backend/tests/test_cron_scheduler.py
• full corrected diff review against current main

Related: #314

Integration verification

• refreshed onto the merged app-job authority contract (Make app-job authority explicit #311)
• retained both scheduler and authority regression suites in the only overlapping test file
• 240 targeted scheduler, job, install, and app-route tests passed (3 skipped)