ops: 生产从 NAS 整体迁移到甲骨文云主机

NAS 局域网 IP 因重启被 DHCP 换过两次，磁盘/网络稳定性都不如已经跑着好几个
生产服务的甲骨文机器。整体搬迁：应用 + 数据库都搬走，NAS 只保留 Gitea（这个
仓库的源码托管，未动）。

## 迁移过程（已核对无损）

- MariaDB：NAS 导出（10.11 源库，处理了只有新版本才有的 `/*M!999999` 注释）
  → 导入甲骨文 MariaDB 10.3.39，**20 张表逐条精确 COUNT(*) 比对完全一致**
- 冻结 NAS（停服务）后又 dump 一次核对，确认期间零数据差异，才继续删库
- NAS `garmin_health_lab` 已 DROP DATABASE，备份在本地
  `~/Desktop/Work/backups/garmin_health_lab_nas_backup_20260912.sql.gz`
- 应用部署到 `/opt/garmin-health-lab`，systemd 单元（`ubuntu` 用户，非
  root），和这台机器上的 ai-gateway/auth-hub 同一套约定
- 公网：`https://garmin.zichuan.xyz`，DNS + Caddy 反代 + 自动 TLS，替代原来
  `NAS frpc → 甲骨文:8124` 那条隧道（已从 NAS 的 frpc.toml 精确删除对应段，
  其它转发未动，改完逐条复检过没打断）
- auth-hub 回调地址换成新域名，NAS/旧端口那几条历史回调已清掉
- AI 网关配置改本地回环（网关现在同机了），触发真实生成验证过

## 一个当场拦下来的风险

甲骨文部署完默认开着自动同步。迁移窗口期两边并行跑时，若两边的调度器同时去
刷新 Garmin 令牌，会撞上按账号计算的 SSO 限流（`GarminHealthLab` 仓库
2026-09-03 那次事故的根因，那次修复花了一整天）。确认账号级 auto_sync 设置
本来是关的、这次算侥幸没撞上——不是设计上的保险，所以迁移期间显式在甲骨文这边
加了 `AUTO_SYNC=false`，直接在运行进程里验证过生效，确认 NAS 已冻结、数据无
缺口后才打开。

## 文档 / 脚本同步

CLAUDE.md 明确写过"部署位置会变，排障前先查、不要凭记忆"——这次是第二次踩中
同一类问题（上次是"NAS 有没有生产环境"判断错），所以把 CLAUDE.md / PROGRESS.md
/ README.md / docs/* 里的部署事实全部更新，NAS 时代的 `deploy/` 脚本加废弃
说明保留参考、不删除，新增 `deploy/push_oracle.sh`（当场跑通一次真实部署）。

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

backend/.env.example

@@ -8,14 +8,15 @@ DB_TYPE=sqlite
 # SQLite file (used when DB_TYPE=sqlite)
 DATABASE_PATH=./data/health.db
 
-# MariaDB (used when DB_TYPE=mariadb) — production DB on the NAS
-# (192.168.50.64, MariaDB 10.11). Connection is over the socket
-# /run/mysqld/mysqld10.sock (or TCP 127.0.0.1:3306) as root; the socket path
-# only matters when TCP auth is disabled for the app user.
-# MARIADB_SOCKET=/run/mysqld/mysqld10.sock
+# MariaDB (used when DB_TYPE=mariadb) — production DB is co-located with the
+# app on the Oracle box (129.146.26.249, MariaDB 10.3.39), TCP 127.0.0.1:3306,
+# dedicated account (not root). MariaDB treats `user@localhost` and
+# `user@127.0.0.1` as two different accounts — if you create this user by
+# hand, create both host variants with the same password, or TCP connections
+# fail with a password that looks right but is not the one that account has.
 # MARIADB_HOST=127.0.0.1
 # MARIADB_PORT=3306
-# MARIADB_USER=root
+# MARIADB_USER=garmin
 # MARIADB_PASSWORD=your_production_mariadb_password
 # MARIADB_DATABASE=garmin_health_lab
 
@@ -38,9 +39,10 @@ AUTH_HUB_CLIENT_ID=your_client_id
 AUTH_HUB_CLIENT_SECRET=your_client_secret
 #
 # Callback URL (must exactly match what's registered in auth-hub). Production
-# registers both the public frp address (129.146.26.249:8124) and the LAN
-# address (192.168.50.64:8124).
-AUTH_HUB_REDIRECT_URI=http://129.146.26.249:8124/auth/callback
+# registers https://garmin.zichuan.xyz/auth/callback — add/remove redirect
+# URIs on that client with /opt/auth-hub's manage_clients CLI, not by editing
+# auth-hub's own database directly.
+AUTH_HUB_REDIRECT_URI=http://127.0.0.1:5500/auth/callback
 
 # --- CORS (comma-separated allowed front-end origins) ---
 # localhost stays in the production list on purpose: CORS is not an auth
@@ -57,9 +59,12 @@ CORS_ORIGIN=http://localhost:3000,http://localhost:5173
 # absorbs single-vendor quota limits. Reached directly, bypassing any local
 # HTTP proxy. NOTE: its NVIDIA upstream is a large reasoning model — replies
 # can take 2-3 minutes, so set AI_TIMEOUT_SECONDS accordingly.
-# HTTPS (Caddy, strips the /ai prefix) rather than http://…:5100 — the token
-# rides in an Authorization header and should not cross the internet in clear.
-AI_GATEWAY_BASE_URL=https://ai.zichuan.xyz/v1
+# Production (co-located with ai-gateway on the same Oracle box) uses the
+# loopback address — skips Caddy and the public hop entirely, and the token
+# never leaves localhost either way. Use the HTTPS domain instead only when
+# this app runs somewhere else: the token rides in an Authorization header
+# and must not cross the public internet in the clear.
+AI_GATEWAY_BASE_URL=http://127.0.0.1:5100/v1
 AI_GATEWAY_TOKEN=
 AI_GATEWAY_MODEL=ai-gateway-auto