[Bug / Billing] Reset Card rewrites the reset anchor instead of granting an extra reset — 重置卡实为改写刷新锚点，而非额外重置

Category: 计费 / 配额 · Billing / Quota
Severity: 影响体验 · Major
Reproducibility: 必现 · Always（至少三名用户独立复现）
Framework: 不涉及框架 · Not framework-specific

TL;DR (EN)

The anniversary Reset Card does not grant an additional reset. Its actual behavior is
quota refilled; next_reset := card_usage_time + period — the user's next natural reset
is silently forfeited. Reproduced independently by at least three users (evidence below).
The announcement disclosed only the refill half of this behavior.

官方话术 vs 实际行为

9/1 官方公告（@Zai_org）：

用掉后，5 小时额度和每周额度都会直接补满，不用等各自的刷新周期。

这句话在技术上无可指摘——额度确实补满了。只是没有人告诉用户后半句：
用卡后，5 小时/每周额度的刷新锚点会被改写为用卡时刻，原本即将到来的自然刷新随之作废。

实际实现用一行公式即可概括：

额度补满 + 下次刷新时间 := 用卡时刻 + 周期

这不是"额外提供一次额度重置机会"，这是"把用户自己的重置换个时间交付"。

我的时间线

• 原刷新锚点：每周一 18:00（下次自然重置应为 9/7 18:00）
• 9/7 06:57 使用重置卡，额度立即补满 ✓（话术兑现）
• 9/7 18:00：自然周重置未发生 ✗
• 当前后台显示下次刷新：9/14 06:57 = 用卡时刻 + 7 天

净效果：本周期内我获得的重置次数与不使用重置卡时完全相同，一次不多。
唯一的区别是原定 18:00 到账的重置被提前到 06:57 交付，且 18:00 那次被静默取消。

社区独立复现（非个例）

• linux.do，9/1（发卡当日）：用户 z9961 用卡后观察到"用了之后变重置时间：2026-09-08"
  ——9/1 用卡，下次刷新 = 9/8（+7 天）。同帖用户 m1zore 在用卡前就已提问
  "重置后我的下一次刷新还是 7d 后吗？如果我再过 24 小时就自然刷新周额度了，
  现在值得用吗"——用户合理预期与实际行为的落差，在发卡当天就已显现。
• linux.do，9/3：用户 AIROBOT 起初回答"不会推迟"，同日实测一张周重置卡后改口并附截图：
  "会推迟的。刚才去用了一张周重置卡，直接把 5H、周全部时间推迟了"
  ——5 小时窗口与周额度两个锚点均被改写。

三个独立用户、三个不同日期、同一个算式：下次刷新 = 用卡时刻 + 周期。
行为确定性高，稳定可复现。

为什么这是个问题

• 用卡前无法知情，决策必然受损：距自然刷新 11 小时的用户用卡（我的情况），
  等价于把一笔即将免费到账的重置换成"立即到账"——这份礼物的净价值为零，
  而用户在点击确认时没有任何途径知晓这一点。若知晓，理性决策显然是等 18:00 之后再考虑用卡。
  同一张卡：额度刚耗尽的用户获益，临近自然刷新的用户受损——两类用户用卡前无法区分自己的处境。
• 这份"回馈"的会计学：对发放方零边际成本（用户获得的重置总次数不变），
  对领取方零边际额度（同上）。作为对照，8/11 百万用户里程碑的全员统一重置
  让每位用户实际多得了一次满额——那才是"回馈"二字通常的含义。
  本次的重置卡，坦率地说，更接近一次**"预约改签"，而非"赠票"**。

期望的行为 / 建议

1. 最低要求：在公告与用卡确认页明示——"使用后，5 小时/每周额度的刷新周期将从
   当前时刻重新计算，原定的自然刷新将不再发生。"
2. 更优解：将补满与锚点解耦。真正意义上的"额外一次重置"应保留用户原有刷新周期。
3. 对已受影响用户的处理：对在自然刷新前夕用卡、实际损失一次完整周期重置的用户
   （服务端日志可精确识别：用卡时刻距原锚点不足一个周期的用户），恢复原锚点或等值补偿。

行为可稳定复现：任意账号在自然刷新前 N 小时用卡，观察下次刷新时间变化即可。
我方持有完整时间线截图，可按需提供。

No files, tests, or entry points are named. Start by reproducing the reset-card behavior near a natural 5-hour or weekly refresh, then locate the billing/quota reset logic and its tests. Done means the intended reset semantics are agreed, the next-reset anchor behaves accordingly, and the affected behavior is covered by verification.