fix(garmin): 刷新出来的令牌从来没写回库，于是每次连接都重换一次

「又被限流了」的根因找到了，不是请求量，是令牌。

`_connect` 里 `refresh_oauth2()` 换来的新 OAuth2 令牌只活在进程内存里——
`save_token` 只在绑定账号时调用过一次。于是每次客户端缓存过期（15 分钟）、
每个 gunicorn worker、每次部署重启，都从库里读回**同一个已过期的令牌**，
然后再做一次真实 SSO 换令牌。而 SSO 端点是按账号限流最狠的那个，社区报告能
封 48 小时（garth #217、python-garminconnect #337）。我今天为了部署重启了
八次服务，每次都清掉缓存。

- `refresh_oauth2()` 成功后 `_persist_token()` 写回。拆出这个函数是因为它和
  `save_token` 想要的正好相反：重新绑定要作废现有会话，持久化刷新结果必须
  保住刚刚产出它的那个会话
- 写回时不带 garmin_email，否则 upsert 会把绑定邮箱刷成 NULL，数据同步页会
  忘记绑的是哪个账号
- 刷新加进程内锁，并在拿到锁后重读一次库：另一个线程刚换过就直接用它的，
  不再自己去换一次
- 五条测试盯住这个不变量，包括「冷缓存不该再换一次」（这条如果回归，就是同一
  个 bug 再来一遍）

顺带把数据端点也节流了——那是另外一半问题，不是这次的病因，但一天历史要 9 次
调用，730 天全历史 6600 个请求全速打出去，不该指望佳明一直容忍：

- services/garmin_throttle.py：代理包住 client，所有调用（含以后新加的）都经
  同一个收口，按间隔排队并计数
- 0.5s 是查过的：garmin-data-export 默认 0.15s、garmin-connect-scraper 默认
  3s、官方合作方 API 100 次/分钟（0.6s）。依据写在文件顶部
- 单次同步 1200 个请求预算，跑满就干净收尾、下次接着跑（已存的天数本来就跳过）
- 运动详情每次最多补 40 条——新账号几百条，不限量就是一次性打光预算

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -111,9 +111,16 @@ cd backend && .venv/bin/python tests/smoke.py
    ——自定义组件里的按钮要显式 `width: auto`（Copilot 浮窗 ✕/发送按钮曾因此
    错位，见 `Copilot.css` 注释）。F7 `.navbar .left/.right` 的 frosted pill 也
    需在 `f7theme.css` 覆盖。
-4. **同步限流**：Garmin 账号 429 退避 24h，`rate_limited_until` 以 **DB 为准**
-   （多 worker 内存不一致会卡死守卫）；`_is_rate_limited` 沿异常 `__cause__`
-   链识别 RetryError 里的 429。
+4. **同步限流**：真正把账号打进 429 的是 **SSO 换令牌端点**，不是数据端点。
+   `refresh_oauth2()` 刷出来的新令牌**必须写回 DB**（`_persist_token`）——不写回
+   的话，每次客户端缓存过期（15 分钟）、每个 gunicorn worker、每次部署重启，都会
+   从库里读回同一个过期令牌再换一次，而这个端点按账号限流、能封几小时。
+   2026-09-03 排查一整天的根因就是这个。
+   数据端点另有节流：所有调用经 `services/garmin_throttle.py` 的代理，默认间隔
+   0.5s + 单次预算 1200 次（依据见该文件顶部）。
+   429 退避 24h，`rate_limited_until` 以 **DB 为准**（多 worker 内存不一致会卡死
+   守卫），且只作**信息**不作闸门；`_is_rate_limited` 沿异常 `__cause__` 链识别
+   RetryError 里的 429。
 5. **AI 生成慢**：网关上游推理模型单次 2~5 分钟，晨报走后台生成 + 轮询，
    接口超时/流式不可靠见 `services/ai.py` 的非流式回退；生产队列并发
    `AI_JOB_CONCURRENCY=2`（共享网关，太高会把别家打成 502）。