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>

backend/.env.example

@@ -101,3 +101,18 @@ AI_JOB_GAP_SECONDS=5
 # Set AI_JOBS=false to stop consuming entirely (screens then show the computed
 # figures with no model reading).
 AI_JOBS=true
+
+# --- Garmin 请求节流 ---
+# 一天的历史要 9 次 API 调用（_extract_daily 6 + daily_extras 3），短同步再加
+# 5 次曲线，每条没有详情的运动 1 次。730 天全历史 ≈ 6600 个请求。以前是能发多
+# 快发多快。
+#
+# 0.5 秒的依据（2026-09-03 调研，见 services/garmin_throttle.py 顶部注释）：
+# sirredbeard/garmin-data-export 默认 0.15s、evg656e/garmin-connect-scraper
+# 默认 3s、佳明官方合作方 API 是 100 次/分钟（合 0.6s）。
+GARMIN_MIN_INTERVAL_SECONDS=0.5
+# 单次同步的请求预算。跑满就干净收尾，下次接着跑（已存的天数会跳过）。
+# 1200 × 0.5s ≈ 10 分钟，够覆盖四个月历史。
+GARMIN_REQUEST_BUDGET=1200
+# 每次同步补多少条运动详情。新账号有几百条，不限量就是一次性打光预算。
+GARMIN_DETAILS_PER_SYNC=40