Fix concurrent applySchedules invocation

[devhawk]

Port of dbos-inc/dbos-transact-py#741 to Java.

Problem

SchedulesDAO.applySchedules implemented "create or replace" as DELETE followed by INSERT (with a freshly generated schedule_id every time). Two concurrent applySchedules calls for the same schedule name could interleave their delete/insert pairs and collide on the schedule_name unique constraint. The new schedule_id on every apply also meant a schedule's identity churned on every edit.

Fix

• SchedulesDAO: replaced delete+insert with a single INSERT ... ON CONFLICT (schedule_name) DO UPDATE, making applySchedules idempotent and race-free. On conflict, schedule_id, status, and last_fired_at are preserved from the existing row; only the definition fields (workflow name/class, cron, context, backfill flag, timezone, queue) are updated.
• SchedulerService: since schedule_id no longer changes on re-apply, the poller can no longer rely on a new ID to detect an edited schedule. Added RunningSchedule, a record snapshotting each running schedule's definition fields (excluding identity/status/runtime state) plus its current ScheduledFuture, keyed by schedule id in a single map (runningSchedules). Each poll compares the live schedule against the snapshot via RunningSchedule.matches(...); on a mismatch, the schedule's future is cancelled and restarted with the new definition (no backfill on restart — only on first start).