feat(api): 个人资料/单位/同步偏好 + 运动详情 + 身体年龄

设置 (services/settings.py, routes/settings.py)
- user_settings 表：身高/体重/出生日期/性别/单位/自动同步开关/同步频率/历史范围
- GET|PUT /api/settings，GET /api/settings/options（取值由后端给，前端不臆造）
- GET /api/settings/rating-basis：把每条参考区间的来源公开出来。
  一个把数字标成「偏低」的区间是在下判断，用户有权看到依据。

运动详情 (services/garmin.py)
- GET /api/garmin/activities/<id>/detail：概览/分段/心率区间/天气/装备/采样曲线
- 首次打开回源 Garmin 并落库，之后走缓存；?refresh=1 强制刷新
- 采样点在写入时抽稀到 300，手机图表画不了更多，也免得整行撑大

身体年龄 (services/fitness_age.py)
- 0.2.8 版 garminconnect 没有 fitnessage 接口，改为本地按公开常模推算：
  VO₂max 对应年龄为基准，静息心率与 BMI 做有上限的修正
- 返回每一步的中间值，界面照实展示，不做成一个不可追溯的分数
- 高于参考表最年轻一档时按 20 岁计——那里外推会得到「11 岁」这种结果

调度器改为每 5 分钟 tick，是否该同步按各账号自己的频率判断

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

backend/db.py

@@ -156,6 +156,38 @@ CREATE TABLE IF NOT EXISTS garmin_mfa_sessions (
   FOREIGN KEY (user_id) REFERENCES users(id)
 );
 
+-- Per-user profile and preferences.
+-- Height/weight/birth date/sex are here rather than on `users` because they
+-- are body measurements the owner edits over time, not identity; and because
+-- the rating bands and the fitness-age estimate need them, an account without
+-- them still works, just with fewer personalised readings.
+CREATE TABLE IF NOT EXISTS user_settings (
+  user_id VARCHAR(64) PRIMARY KEY,
+  height_cm DOUBLE,
+  weight_kg DOUBLE,
+  birth_date DATE,
+  sex VARCHAR(16),
+  units VARCHAR(16),
+  auto_sync INT,
+  auto_sync_minutes INT,
+  history_days INT,
+  updated_at DATETIME,
+  FOREIGN KEY (user_id) REFERENCES users(id)
+);
+
+-- Full detail for one activity, exactly as Garmin returned it.
+-- The list view stores only the summary columns; opening an activity needs
+-- laps, heart-rate zones and the sampled series, which are far too large to
+-- carry on every list request. Fetched on demand and kept, so the second
+-- visit costs nothing and works offline.
+CREATE TABLE IF NOT EXISTS activity_details (
+  activity_id VARCHAR(64) PRIMARY KEY,
+  user_id VARCHAR(64) NOT NULL,
+  payload MEDIUMTEXT,
+  fetched_at DATETIME,
+  FOREIGN KEY (user_id) REFERENCES users(id)
+);
+
 -- One cached LLM answer per user. Generating one takes minutes against a
 -- large reasoning model, which is far too slow to sit in a page load, so the
 -- result is stored and reused until the underlying data changes.