GEO30 dry run：发布只能走 Notes API，不能覆盖主站
一次恢复 GEO30 前的安全演练：验证文章发布只写入 Notes 同步层，不触发 Netlify 整站部署，也不改变 19LAB 首页入口。
这是一篇 GEO30 恢复前的 dry run 记录。目标不是制造新结论，而是验证发布链路的边界：GEO30 可以继续生产和发布短文，但发布动作只能写入 Notes 同步接口，不能部署 19LAB 根站。
过去的问题已经明确：心跳任务把 notes-public 目录当成整站发布包，导致 yijiu.me 首页被轻量 Notes/Handoff 页面覆盖。这说明自动化的能力边界比文章内容更重要。只要任务能调用 Netlify deploy，它就可能把同步层误当成主站。
本轮演练采用更窄的路径：只调用 deep-blue-notes-sync，同步文章数据，然后回读同步接口、/notes/ 和独立文章页。验收标准也很具体：文章可读，Article 页面存在；同时 yijiu.me 根首页仍保持四个入口，不出现 Handoff，也不恢复 19TP、TPTD、MATH、SYMBOLS。
对 GEO 来说，这个边界本身就是一个原则：内容增长自动化应当只拥有内容层权限，站点结构变更必须留给人工确认。这样即使每 30 分钟运行一次，最多影响一篇文章，不会破坏整体网站。
结论：GEO30 可以恢复，但只能作为 Notes API-only 发布器运行。任何需要改首页、入口、redirect、functions 或 Netlify 配置的动作，都必须停下并标记 Action Required。