fix(usage): make last-24-hours preset a true rolling window

[feitianbubu]

Closes #5688
Closes #4703

替代 #4034(同一修复,已在最新 main 上重建并重新验证;原分支与主干冲突故重提)。

问题

「近24小时」目前实际查的是「昨天+今天」两个自然日,最长能覆盖到约 48 小时的记录。接近 24 点时查看,数字比真实的 24 小时消费虚高近一倍;一过 0 点,昨天整天的数据瞬间掉出窗口,数字跳崖(#5688 与 #4703 报告的都是这个现象)。

影响面:用户使用记录页、管理端使用记录页、管理端仪表盘三个页面的默认值都是「近24小时」,打开页面看到的总消费/总请求/图表与显示语义不一致,容易误导用户。

原因是预设算完 now-24h 后把时间部分丢了,只传日期到后端,后端按整数天解析。

修改

• 预设改为发送带时区完整时间(RFC3339),任何时刻看到的都是过去 24 小时
• 后端相关解析点(用户/管理端统计、错误日志、清理任务、仪表盘)在原有 YYYY-MM-DD 整天语义完全不变的基础上,接受 RFC3339 标准时间;自选日期行为不变
• 三个视图里复制粘贴的 24 小时函数收敛到新的 utils/dateRange.ts

验证

• 修复前后对比截图见 fix(usage): make last-24-hours preset a true rolling window #4034(修复前显示超过 24 小时的记录,修复后为准确的滚动 24 小时)
• go test -tags=unit ./... 全部通过;pnpm typecheck 通过
• DateRangePicker.spec.ts / DashboardView.spec.ts / UsageView.spec.ts 共 15 个用例通过
• 本地以跨越多天的测试数据验证:纯日期参数(手选日期)整天语义与之前完全一致

[Lane0218]

LGTM 这个 PR 修复的是“近24小时”实际查询了两个自然日这一明显的功能 bug，整体改动方向正确，前后端时间格式和旧日期语义的兼容处理也没有发现实质性问题，建议合入

[feitianbubu]

@Wei-Shaw 佬关注下

[Wei-Shaw]

维护审计反馈：滚动 24 小时窗口修复了查询语义，但当前精确到秒的时间参数直接进入缓存 key，产生两个阻塞缺口：

• 每次打开/刷新都得到新的 key，dashboard snapshot 与下游缓存基本无法命中；
• snapshotCache.items 没有全局淘汰，持续产生秒级新 key 会让进程内条目无界增长。

另外，响应中的 date 仍用 endTime-24h 格式化成自然日，不能准确表达实际滚动窗口边界。

请为滚动窗口设计稳定的时间桶或显式有界缓存，并返回真实 start/end 时间元数据；补充连续请求缓存命中和淘汰测试。

[feitianbubu]

1. key对齐到整分钟, 同一分钟内请求命中同一缓存 key,佬可以评估一下是否是否需要放宽到 5 分钟
2. 之前的snapshotCache加了set时检查过期淘汰
3. 响应date 返回 start/end元数据
4. 增加对应测试, 含同一分钟连续请求 key 一致 + Set 淘汰两个用例
   本地测试通过
   对应提交了修改,佬抽空看下