Scheduled execution cancellation can race with queue publication

### Summary Scheduled execution cancellation cannot currently be coordinated atomically with publication to the functions queue. A cancellation can therefore race with the scheduler's claim, publication, and cleanup steps. ### Current behavior One failure path is: 1. The scheduler claims a schedule by setting `active=false`. 2. A concurrent cancellation sees the scheduler's claim and is rejected. 3. Publication to the functions queue fails. 4. The scheduler restores `active=true` for retry. 5. The execution can be collected and run later despite the cancellation attempt. The opposite ordering is also unsafe: if queue publication succeeds but schedule cleanup fails, allowing cancellation of the inactive schedule can return `204` even though the function job is already queued. ### Expected behavior Cancellation should have a linearizable result: - `204` only when publication has been prevented. - A cancellation that loses to publication should be rejected as in progress. - A failed publication should not revive a schedule after cancellation succeeded. ### Suggested direction Use shared per-schedule coordination that spans the scheduler's claim, queue publication, cleanup, and failure compensation, and that is also acquired by the cancellation endpoint. A durable state machine or transactional outbox would provide stronger guarantees; a distributed per-schedule lock may be a smaller initial fix. ### Context Identified while reviewing #13238. The underlying scheduler/queue atomicity concern is broader than execution-log persistence and should be addressed separately.