feat: 提供手动触发签到/余额刷新的入口（HTTP 端点或信号）

[AllenReder]

背景

当前签到与余额刷新只由内部调度器在 schedule.checkin_hours（默认 9/21 点）自动执行，没有对外的触发方式。这带来两个实际不便：

1. 部署/重启后积分长时间显示为 0：credits 初始值 0，只有签到任务调用上游 get-user-resource 后才写入池状态。若在 9 点后、21 点前部署，WebUI / /status 会一直显示 0，直到下一个整点，容易误判为「没积分」。
2. 无法即时验证：想确认账号余额是否恢复、硬冷却（402 余额不足，本应签到解冻）能否提前解除，只能干等到下一个签到时点。

补充：仓库自带的 signin.sh / cmd/signin 是独立进程，能签到但只更新 auth 文件，不会回写运行中容器的内存池状态，因此无法用来刷新 /status。

期望

提供一个手动触发入口，语义与调度器到点时执行的 RunCheckinNow() 完全一致（签到 + 余额查询 + 冷却解冻，末尾顺带旅行）。可参考的实现方向（任选其一）：

• HTTP 端点：如 POST /admin/checkin，挂在 withAuth 下，复用现有 api_key 鉴权；触发后同步或异步执行，返回简要结果（成功/已签到/失败的账号数）。
• 信号触发：监听 SIGHUP（或自定义信号）执行一次 RunCheckinNow()，无需新增路由。

个人更倾向 HTTP 端点：便于 WebUI/脚本集成，也不与容器信号语义混淆。

备注

• 安全上，端点应走 api_key 鉴权，避免暴露成未授权的高频上游调用入口；建议加最小触发间隔（如 60s）防误刷。
• 如果设计上倾向「不做手动触发」，也欢迎说明理由；至少可考虑在启动时对 credits 未知的账号做一次余额拉取，以缓解第 1 点的误导。

[Sliverkiss]

感谢 @AllenReder 的详细反馈，问题描述和现状分析都很到位。

关于现状，你的判断是对的

补充确认一下你提到的关键前提：signin.sh / cmd/signin 是独立的一次性进程，只更新 auths/*.json，不会回写运行中容器的内存池状态——因此确实无法用来刷新 /status。同理，credits 初值为 0，只有签到链路调用上游 get-user-resource 后才会写入池状态，这正是「9 点后、21 点前部署会长时间显示 0」的原因（internal/pool/pool.go）。

你列出的两个痛点在实现层面也成立：RunCheckinNow() 的语义是「签到 → 余额查询 → ReenableIfCredits 解冻 → 收尾跑一趟旅行」（internal/scheduler/scheduler.go:147），且冷却中的账号也参与（签到本身就是为了解冻它们，仅跳过 Disabled）。这套语义目前确实只有调度器能触发。

规划：随 WebUI 一并提供后台 API

WebUI 的设计与开发正在进行中，届时会一并开放后台 API，用于方便地程序化调用。

你提的手动触发签到 / 余额刷新，正是这套后台 API 的自然组成部分——WebUI 本身也需要通过它来展示和刷新账号状态，所以不会单独造一套专用入口。具体路径、请求/响应结构与命名，会在设计定稿后同步到本 issue。

关于你倾向的触发方式，设计上同样倾向 HTTP 端点而非信号，理由与你的判断一致：可与 WebUI 复用同一鉴权面与调用路径，且不与容器的信号语义混淆。你在备注里提的两点也已纳入设计考量：

• 鉴权：端点在 api_key 鉴权下，不作为未授权的高频上游调用入口；
• 防误刷：加最小触发间隔，避免短时间内重复打上游。

你提的兜底方案（启动时对 credits 未知的账号做一次余额拉取，以缓解第 1 点的误导）已记下，会在这部分一起评估。

另外补充一句关于 checkin_enabled 的语义，方便你后续设计调用逻辑时参考：关闭签到会连带停掉猫猫旅行（旅行无独立开关，搭签到时点便车执行），且不再提前解冻被硬冷却（402 余额不足）的账号——这类账号只能等硬冷却次日 04:00 自然到期。手动触发入口上线后，这条链路会多一个即时补救手段。

欢迎 PR

非常欢迎 PR。 注意到你在 #33 也提出可以提供 WebUI 相关实现——两块需求高度耦合（后台 API 是 WebUI 的数据面），如果你有意参与，建议先在 #33 或本 issue 对齐一下接口设计再动手，避免设计与实现返工。

触发方式、鉴权、响应结构这几处一旦定稿，我会在此同步，届时可直接按约定实现。

---

本 issue 保留开启，作为该能力的追踪项；待后台 API 落地后在此更新进展。再次感谢反馈 🙏

[Sliverkiss]

这个需求归并到独立前端管理面板里处理了（#61）：面板作为独立项目维护，只需对接 auth 文件，积分/签到状态直接调用上游接口展示，不依赖网关侧新增触发端点。感谢详细的提议，方案设计时会参考。