feat: 临时不可调度规则支持按时间点重置

[GodD6366]

功能说明

为临时不可调度规则新增 reset_at_time 字段，支持按指定时间点（如每天 00:00）自动恢复账号调度，而非固定时长冷却。

改动内容

后端

• TempUnschedulableRule 结构体新增 ResetAtTime 字段（格式：HH:MM）
• 修改 triggerTempUnschedulable 支持按时间点计算恢复时间
• 若设置了 reset_at_time，则计算到下一个该时间点的时间作为解除时间
• 验证逻辑：duration_minutes 和 reset_at_time 至少填一个

前端

• 时间选择器旁新增「次日0点」快捷填充按钮
• 表单验证支持 duration 或 reset time 二选一
• 新增中英文国际化文本

使用方式

1. 编辑或创建账号
2. 开启「临时不可调度」规则
3. 两种方式任选其一：
   • 设置 持续时间（分钟）：固定时长冷却
   • 设置 按时间点重置：如 00:00 表示每天凌晨 0 点重置

两者都填时，优先使用 reset_at_time。

[github-actions]

All contributors have signed the CLA. ✅
_{Posted by the CLA Assistant Lite bot.}

[GodD6366]

I have read the CLA Document and I hereby sign the CLA

[GodD6366]

recheck

[Wei-Shaw]

1. reset_at_time 校验不一致，非法值会静默导致规则失效

   位置：backend/internal/service/account.go:322-328、backend/internal/service/ratelimit_service.go:1763-1788、
   frontend/src/components/account/EditAccountModal.vue:3168-3190

   后端 GetTempUnschedulableRules() 只判断 reset_at_time != ""，没有校验格式和范围；真正触发时才解析。结果是如果通过
   API、批量更新或异常前端状态写入 "99:99"、"24:00" 这类值，并且 duration_minutes <= 0，规则会被当成有效配置读取，但触
   发时 triggerTempUnschedulable() 解析失败后直接返回 false，账号不会进入临时不可调度，也没有错误提示或日志。

   前端也只校验 /^\d{2}:\d{2}$/，同样没有限制小时 0-23、分钟 0-59。

   建议：后端提取统一校验/解析函数，至少用 ^([01]\d|2[0-3]):[0-5]\d$ 或 time.Parse("15:04", ...) 校验；无效且无
   duration 时应拒绝保存或跳过并记录日志。前端使用同样范围校验。

2. 时区语义不明确，实际使用服务端本地时区

   位置：backend/internal/service/ratelimit_service.go:1760-1778

   当前用 time.Now().Location() 计算下一个重置时间。这意味着 00:00 是服务进程所在时区的午夜，不一定是管理员浏览器时
   区，也不一定是上游订阅/配额重置时区。容器默认 UTC 时，中文界面里的“次日0点”可能实际变成中国用户看到的早上 8 点。

   建议：明确产品语义。最低成本是在 UI 文案中说明“按服务器时区”；更稳妥是使用配置化时区，例如系统设置或环境变量，并在
   前端展示当前生效时区。

3. 英文界面存在硬编码中文按钮

   位置：frontend/src/components/account/CreateAccountModal.vue:2022-2027、frontend/src/components/account/
   EditAccountModal.vue:1221-1227

   快捷按钮文本写死为 次日0点，没有走 i18n。英文界面会混入中文。

   建议：新增 resetAtMidnightShortcut 或类似 i18n key，英文可为 Next 00:00 / Midnight，中文为 次日0点。

4. 新功能缺少专门测试覆盖

   现有 backend/internal/service/temp_unsched_test.go 只覆盖旧的 duration 规则解析，没有覆盖 reset_at_time。这个 PR 的
   关键逻辑是时间计算，CI 通过并不能证明新功能正确。

   建议至少补：

   • reset_at_time 单独生效，duration_minutes=0
   • 当前时间早于目标时刻，使用当天目标时刻
   • 当前时间晚于目标时刻，使用次日目标时刻
   • 非法 reset_at_time + 无 duration 时不应静默作为有效规则
   • 非法 reset_at_time + 有 duration 时的预期行为
   • 前端构造规则时拒绝 24:00、99:99