refactor: remove RescheduleIn and RescheduleAt from JobCompletion

[nicolasburtey]

Summary

• Remove RescheduleIn, RescheduleInWithOp, RescheduleInWithTx variants from JobCompletion
• Remove RescheduleAt, RescheduleAtWithOp, RescheduleAtWithTx variants from JobCompletion
• Remove corresponding dispatcher match arms
• Callers should use RescheduleNow* variants instead

Test plan

• cargo check --features es-entity passes
• Existing tests pass (no test code used removed variants)

🤖 Generated with Claude Code

---

Note

Medium Risk
Medium risk because this is a breaking public API change that removes JobCompletion::RescheduleIn*/RescheduleAt* and corresponding dispatcher handling, requiring downstream callers to change how they schedule follow-up work.

Overview
Removes the delayed (RescheduleIn*) and absolute-time (RescheduleAt*) rescheduling outcomes from JobCompletion, leaving only the immediate RescheduleNow* variants.

The dispatcher no longer matches or applies duration/timestamp-based reschedules, and crate docs were updated to reflect the reduced rescheduling API (including dropping chrono usage from runner.rs).

^{Written by Cursor Bugbot for commit b981cdd. This will update automatically on new commits. Configure here.}

[bodymindarts]

This removes the ability for cron-style jobs... I don't understand

[nicolasburtey]

there are not any cron-job left since refactoring to EOD for many events.

cron job are incompatible with a manual clock / more deterministic system, so we should just not allow them

[bodymindarts]

What about fetching price in an interval?

[nicolasburtey]

afaik they are permanent job that just sleep between price fetch, ie the job run forever and just sleep in its own "thread" between price update

[nicolasburtey]

But maybe there is one use case for it: if there is a margin call and a 24h or 48h to react for the customer. Not sure how this would be implemented without this. We don't do this type of margin call yet

[bodymindarts]

I wouldn't remove these just yet...