fix(deploy): S99garmin.sh 丢了可执行位，重启两天没人发现服务已经死了

09-06 07:08 NAS 重启（DHCP 顺带把它的局域网地址从 .64 换成了 .65），佳明健康
服务再也没起来——两天后才被发现。

根因：`deploy/S99garmin.sh` 本地就没有 +x（`-rw-r--r--`，另外三个部署脚本都是
`-rwxr-xr-x`）。DSM 的 rc.d 启动器碰到一个没有执行权限的软链接目标，既不执行
也不报错，静默跳过。push.sh 用 tar 同步 deploy/ 目录会原样带走权限位，所以自
09-01 起只要重新部署一次，就会把 NAS 上（原本可能是手工修过的）可执行权限
再次覆盖回不可执行——这颗雷从那天就埋下了，直到这次重启才被踩到。

- 本地补上 S99garmin.sh 的 +x
- push.sh 同步完 deploy/ 之后显式 chmod +x 三个会被开机脚本或部署流程直接
  执行的文件，并断言生效——以后这个位再丢，部署会报错退出，不会再悄悄失效
  到下次重启才现形
- push.sh 的默认目标 IP 也是这次连带发现的坑：硬编码的 192.168.50.64 已经
  证明会被 DHCP 换掉，改成当前地址 .65 并加注释——真正的解法是给 NAS 做
  DHCP 保留（MAC 90:09:d0:22:a6:33），不在这次改动范围内

现场同时处理：手动 chmod +x 后 sh start.sh 拉起服务；frpc 配置里的
localIP 硬编码着 192.168.50.64（同样的病），改成 127.0.0.1 后不再受局域网
IP 变化影响，公网已验证恢复。frpc 改动是 NAS 系统配置，不在这个仓库里，
旧文件备份在 NAS 的 /etc/frp/frpc.toml.bak-20260908。

遗留：auth-hub 注册的 LAN 回调地址还是 http://192.168.50.64:8124/auth/callback
（CLAUDE.md:99），局域网内直接用 .65 访问会在登录环节被拒；公网入口不受影响。
要不要把它也换成 DHCP 保留后的固定地址，留给用户决定。

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

deploy/push.sh

@@ -15,7 +15,11 @@
 # Never touches .env, .venv or the database on the far side.
 set -e
 
-HOST="${1:-ericwyuan@192.168.50.64}"
+# DHCP-assigned and has already changed once (192.168.50.64 -> .65 on the
+# 2026-09-06 reboot) — this default will go stale again after the NAS's next
+# reboot unless a DHCP reservation is set for it on the router. Until then,
+# pass the current IP explicitly: `./deploy/push.sh ericwyuan@<ip>`.
+HOST="${1:-ericwyuan@192.168.50.65}"
 PORT="${2:-2222}"
 # Needed for the sudo restart below. Prompted for rather than stored, and only
 # used over the already-authenticated ssh master connection.
@@ -69,6 +73,18 @@ $TAR --exclude .venv --exclude .env --exclude __pycache__ \
 # them.
 echo "==> deploy scripts"
 $TAR -C "$REPO/deploy" . | sh_ "tar xzf - -C '$APP/deploy'"
+# tar carries whatever bit the local file has, and it silently had none:
+# S99garmin.sh lost +x at some point before this repo existed, every deploy
+# since then re-clobbered the NAS's copy back to non-executable, and nothing
+# noticed until a 2026-09-06 reboot left the service down for two days —
+# DSM's rc.d runner does not execute a script it cannot execute, and does not
+# warn either. Asserted here so a future loss of the bit fails the deploy
+# instead of failing silently at the next reboot.
+sh_ "chmod +x '$APP/deploy/S99garmin.sh' '$APP/deploy/start.sh' '$APP/deploy/stop.sh'"
+if ! sh_ "[ -x '$APP/deploy/S99garmin.sh' ]"; then
+  echo "S99garmin.sh is not executable after chmod — the boot script will not run on the next reboot" >&2
+  exit 1
+fi
 
 echo "==> static (cleared first, so stale JS chunks do not pile up)"
 if [ ! -f "$REPO/client/build/index.html" ]; then