KernelSU 解决方案：任务队列满时计划任务的处理优化

问题概述

在任务调度系统中，当任务计划在预定时间执行时，任务队列已满导致任务无法执行，系统会将任务推迟1分钟重试。然而，这种推迟操作被错误地当作新的基准时间，导致后续任务执行时间也跟着偏移，破坏了原有的执行节奏。

问题代码位置

该问题的代码位于 backend/src/schedules.rs 文件的 run 函数中，具体是在处理 AppError::Busy 错误的分支。

问题细节

1. 在处理 AppError::Busy 错误的分支中，系统将 next_run_at 设置为 now + BUSY_RETRY_MS。
2. 在下一次任务执行时，读取到的 due 值已经是这个被推迟的时间，导致 following(due, interval, now) 函数根据这个推迟值计算后续的任务执行时间。
3. 由于 request_key = schedule-{id}-{due} 也发生了变化，这与注释中所述的“重试同一个槽位”不一致。

示例说明

假设有一个每60分钟执行一次的计划任务，首次预定在10:00执行。如果在10:00遇到队列满的情况，任务会被推迟到10:01执行。之后，任务会在11:01、12:01依次执行。如果再次遇到队列满的情况，任务会再次被推迟，导致执行时间持续偏移。

期望行为与解决方案

期望的行为是只推迟本次任务，而不改变原有的执行节奏。为此，建议修改代码逻辑，确保在任务被推迟时，后续任务的执行时间不会受到影响。同时，建议增加一个覆盖 Busy 路径的测试用例，以确保问题得到有效解决。

优化建议

1. 保持 next_run_at 的值不变，仅在任务实际执行时更新时间。
2. 修改 request_key 的生成逻辑，确保在任务被推迟时，仍然能够重试同一个槽位。
3. 增加测试用例，覆盖任务队列满时的处理路径，确保系统的健壮性和稳定性。

通过这些优化措施，可以有效解决任务队列满时计划任务执行时间偏移的问题，提高系统的可靠性和用户体验。