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>

PROGRESS.md

@@ -10,13 +10,55 @@
 
 - [x] Gunicorn 生产服务器配置（2 workers / 4 threads）
 
-- [x] 部署到本地 NAS（`/volume1/web/garmin-health-lab`），端口 8124
+- [x] ~~部署到本地 NAS（`/volume1/web/garmin-health-lab`），端口 8124~~ 已下线，见下
 
-- [x] frp 隧道配置，通过甲骨文公网 IP 外网访问（`http://129.146.26.249:8124`）
+- [x] ~~frp 隧道配置，通过甲骨文公网 IP 外网访问（`http://129.146.26.249:8124`）~~ 已拆除
 
-- [x] 开机自启脚本（`deploy/S99garmin.sh`）
+- [x] ~~开机自启脚本（`deploy/S99garmin.sh`）~~ 已移除，脚本保留仅供参考
 
-- [x] 甲骨文 iptables 放行 8124 端口
+- [x] ~~甲骨文 iptables 放行 8124 端口~~ 该端口不再使用
+
+### 迁移到甲骨文云主机（2026-09-12）
+
+NAS 的局域网 IP 因 DHCP 重启换过两次（`.64` → `.65` → 又变回 `.64`），且磁盘/
+网络都不如已经稳定跑着好几个服务的甲骨文机器可靠。整体搬迁，NAS 只保留 Gitea
+（这个仓库的源码托管，未动）。
+
+- [x] 甲骨文本机新建 MariaDB 库 `garmin_health_lab` + 独立账号 `garmin`（同时建
+  `garmin@localhost` 与 `garmin@127.0.0.1` 两个 host 变体、同密码——MariaDB 视
+  为两个不同账号，只建一个会导致 TCP 连接失败）
+
+- [x] NAS `mysqldump`（10.11 源库，处理了 `/*M!999999` 注释兼容 10.3 目标）→
+  导入甲骨文 MariaDB 10.3.39，**20 张表逐条精确 `COUNT(*)` 比对完全一致**才继续
+
+- [x] 应用部署到 `/opt/garmin-health-lab`，systemd 单元 `garmin-health-lab.service`
+  （`ubuntu` 用户，非 root；和 ai-gateway/auth-hub 同一套约定）
+
+- [x] DNS：腾讯云 DNSPod API 新增 `garmin.zichuan.xyz` A 记录；Caddy 反代 +
+  自动签发 TLS，实测已生效
+
+- [x] auth-hub 回调地址改为 `https://garmin.zichuan.xyz/auth/callback`，清掉
+  NAS/旧公网端口那几条历史回调
+
+- [x] AI 网关配置从公网域名改本地回环 `http://127.0.0.1:5100/v1`（网关和本服务
+  现在同机），**触发真实生成验证通过**（`upstream: gemini`）
+
+- [x] 迁移窗口期加了安全阀：甲骨文这边先 `AUTO_SYNC=false`，避免和 NAS 的调度
+  器同时刷新 Garmin 令牌撞上按账号计算的 SSO 限流（见下方"同步逻辑修复"一节
+  09-03 那次事故）。确认 NAS 已冻结、数据无缺口后才在甲骨文打开
+
+- [x] 冻结 NAS（停 gunicorn）→ 补一次终态 dump 核对无数据差异 → 移除开机自启
+  → `DROP DATABASE garmin_health_lab`（备份在本地
+  `~/Desktop/Work/backups/garmin_health_lab_nas_backup_20260912.sql.gz`）
+
+- [x] NAS frpc 配置精确删除 `garmin-health` 转发段，`gitea`/`wordpress`/
+  `fam-core`/`nexusai` 几条未动，改后逐条复检确认其它站点未受影响
+
+- [x] 新部署脚本 `deploy/push_oracle.sh`（key 认证 + systemd，校验 PID 变化 +
+  health 200），落地当场跑通一次真实部署
+
+- [x] `CLAUDE.md` 部署章节整体重写；NAS 时代的 `deploy/` 脚本加了废弃说明保留
+  参考，未删除
 
 ### 认证