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>

README.md

@@ -20,9 +20,9 @@
 
 ### 后端
 - Python 3.10+ + Flask（应用工厂）
-- Gunicorn（生产运行，NAS :8124）
-- 可插拔数据层：SQLite（本地开发）/ MariaDB（生产，NAS 10.11 库
-  `garmin_health_lab`，经 PyMySQL/socket）
+- Gunicorn（生产运行，甲骨文云主机 :5500，Caddy 反代出 `garmin.zichuan.xyz`）
+- 可插拔数据层：SQLite（本地开发）/ MariaDB（生产，与应用同机的 10.3.39 库
+  `garmin_health_lab`，经 PyMySQL/TCP）
 - JWT 鉴权；登录走 auth-hub 统一 SSO（OAuth2/OIDC，本地密码登录已移除）
 - garminconnect（Garmin API 集成）
 
@@ -93,8 +93,8 @@ CORS_ORIGIN=http://localhost:3000,http://localhost:5173
 数据层通过 `DB_TYPE` 环境变量切换后端，**业务代码无需改动**：
 
 - **SQLite（默认，本地开发）**：零配置，由 `DATABASE_PATH` 指定文件位置。
-- **MariaDB（生产）**：运行于 NAS（192.168.50.64）本地 MariaDB 10.11，root 经
-  socket `/run/mysqld/mysqld10.sock`（或 TCP `127.0.0.1:3306`）连接（PyMySQL），
+- **MariaDB（生产）**：运行于甲骨文云主机（`129.146.26.249`）本地 MariaDB
+  10.3.39，独立账号 `garmin` 经 TCP `127.0.0.1:3306` 连接（PyMySQL），
   独立库 `garmin_health_lab`。完整配置见 `backend/.env.example`：
 
 ```env
@@ -195,15 +195,17 @@ python tests/smoke.py
 > 轮询，趋势归因与 Copilot 走显式触发；任一模型失败时降级为规则引擎，
 > `meta.source` 会说明本次由谁作答。
 
-## 🚀 部署（生产 = NAS）
+## 🚀 部署（生产 = 甲骨文云主机，2026-09-12 起）
 
-- **位置**：NAS `192.168.50.64` `/volume1/web/garmin-health-lab`，root 跑
-  gunicorn `0.0.0.0:8124`（2 workers / 4 threads / --timeout 300），开机自启
-  DSM 任务调度器执行 `deploy/S99garmin.sh`。
-- **公网**：NAS frpc → `http://129.146.26.249:8124`。
-- **一键部署**：先 `npm run build`，再 `./deploy/push.sh`（同步 backend +
-  deploy + 清空重推 `client/build` + sudo 重启 + pid/health 双校验）。
-- **部署排障前**：先读 `PROGRESS.md` 与 `deploy/` 脚本确认事实。
+- **位置**：`129.146.26.249` `/opt/garmin-health-lab`，`ubuntu` 用户跑
+  gunicorn `127.0.0.1:5500`（2 workers / 4 threads / --timeout 300），
+  systemd 单元 `garmin-health-lab.service`。
+- **公网**：`https://garmin.zichuan.xyz` → Caddy → `127.0.0.1:5500`。
+- **一键部署**：先 `npm run build`，再 `./deploy/push_oracle.sh`（ssh key 同步
+  backend + 清空重推 `client/build` + pip install + systemctl restart +
+  PID/health 双校验）。
+- **部署排障前**：先读 `PROGRESS.md` 与 `deploy/` 脚本确认事实——部署位置换过
+  一次（NAS → 甲骨文），凭记忆断言曾经出过错。
 
 ## 🔐 安全说明