fix(garmin): 登录端点的 429 在封锁期内再试会延长封锁，唯独这一处要停手

实测记录：昨天为了验证令牌写回的修复，我发了一次 1 天同步，把 rate_limited_until
从 09-04T00:41 推到了 09-04T15:26——一次尝试，延长十五小时。

Garmin 的登录/换令牌端点和数据端点是两套规则：
- 数据端点的 429：本地冷却只是估算，过一会儿发个真实请求正是确认它有没有解除
  的唯一办法，没解除也不吃亏
- 登录端点的 429：窗口内每次尝试都把窗口往后推。这也是这个账号一直卡着出不来
  的原因——每次同步都去换一次令牌，每次都把封锁续上

所以：
- sync_status 加 rate_limit_source 列，记住 429 是哪个端点给的
- 只有 source=sso 且窗口未过时，才拒绝**刷新令牌**这一个动作

这个闸门刻意做得很窄，因为上一次的教训是「一刀切的闸门会让健康账号白白闲置」：
- 只拦刷新，不拦同步。库里的令牌只要还没过期，冷却期内照常同步
- 数据端点的 429 不参与判断——为了一次指标调用把账号锁一天，比问题本身更糟
- 用户可以推翻它：同步请求带 force 就先清掉冷却记录。那个截止时间是我们自己
  猜的 24 小时，不是佳明说的，所以必须能被推翻

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

backend/routes/garmin.py

@@ -58,6 +58,14 @@ def sync():
     except (TypeError, ValueError):
         days = None
 
+    # `force` overrules the recorded SSO cooldown. That deadline is our own
+    # 24h guess rather than something Garmin told us, so the user has to be
+    # able to say "it has cleared, try anyway" — otherwise a wrong estimate
+    # strands the account for a day, which is the failure that got a blanket
+    # rate-limit gate removed once before.
+    if data.get("force"):
+        garmin_svc.clear_rate_limit(g.user_id)
+
     # Always run in the background: even a week takes ~20s, and a full
     # backfill runs for many minutes. Progress is polled via /status.
     result = garmin_svc.start_sync(g.user_id, creds, days)