开发日志：补上 Linux 时间戳那个坑与发版三段结构

DEVLOG.md

@@ -13,6 +13,8 @@
 ⑦**发版流水线不再走 artifact 服务**（`.gitea/workflows/release.yml` 改了结构）：`upload-artifact` / `download-artifact` 那一套在这台 Windows runner 上传大文件会卡死——客户端连着 5 次重试全是 `Request timeout: .../ArtifactService/CreateArtifact`，而且请求根本没到服务端（服务端日志里连一条都没有）。**改成三步**：`release-prepare`（Linux：抽正文 + 建 Release，**先落草稿**——包还没打出来就公开发布等于发一个空 Release）→ `build`（Windows：打包、冒烟、然后用 `.gitea/scripts/attach-artifacts.js` **把包直接 POST 给实例的 Release 接口**（顺带算 SHA256 清单一起挂上））→ `release`（Linux：只看 Release 上已挂的附件，判草稿；两边齐了才转正式）。**看的是 Release 上的附件，不是哪个 job 手里的文件**——mac 那条腿在另一个工作流里，两边可能先后挂到同一个 Release 上，谁最后挂的那个看到的才是全的。
 ⑧**Gitea 这边不缓存 npm**（`release.yml` 与 `ci-check.yml` 的 `setup-node` 去掉了 `cache: npm`）：那台 Windows 机器的 npm 缓存已经 1.8GB，收尾时打包上传到实例的缓存服务，走公网只有 ~1MB/s——一次收尾就是半小时，**runner 只有一个工位**（maxParallel=1），整趟发版被它堵死。不缓存的话 `npm ci` 从 npmmirror 拉一遍一两分钟。GitHub 那两份（`.github/workflows/*.yml`）保持原样。
 ⑨**实例上那条卡住的 task**：runner 领到活儿中途挂掉时，实例的 `action_task` 里会留一条 `running` 的记录，runner 就一直被算成 busy、**再也不领新活儿**（Gitea 自带的「收僵尸 task」定时任务没生效）。这次是手工把那条改成 `cancelled` 才放开的（先确认对应的 job 早就结束了）。
+⑩**Linux 上才露的一类真问题：文件时间戳取自粗时钟**（`test/tenant.js` 与 `test/code-tools.js` 各一个用例）：判据「这个文件在我读过之后有没有被别人动过」是拿**文件时间戳 + 大小**认的（`fileVersion` / `fingerprint`），而 **Linux 的文件时间戳取自粗时钟（一个 tick 约 4ms）**——**同一个 tick 里的两次写，时间戳一模一样**（实测 20 轮里 19 轮相同；macOS / NTFS 细到纳秒，所以那边看不出来）。于是「读完就改、大小还一样」这种改动就认不出来。**修法**：这两个用例在改文件前等 20ms（`await wait(20)`），把「等一个 tick」写进用例里；**产品代码一个字没动**（Rust 那边早就是这么干的——它的 `t3_stale` 用例改的是大小不同的内容，压根不碰这个边界）。
+⑪**发版流水线新的三段结构跑通了**（`.gitea/workflows/release.yml`）：`test`（Linux，130 个套件全绿）→ `release-prepare`（Linux：抽正文 + **先落草稿**建 Release，把 id 交给下一步）→ `build`（Windows：打包 + `scripts/win-smoke.js` 冒烟 + **把包直接 POST 给实例的 Release 接口**，`.gitea/scripts/…` 那份挪到了 `scripts/attach-release-artifacts.js`——层级守护只认那七层，`.gitea/` 不在层里）→ `release`（Linux：只看 Release 上已挂的附件，判草稿）。**为什么不用 artifact 服务**：那台 Windows runner 往 artifact 服务传大文件会卡死（客户端 5 次重试全是 `Request timeout: .../ArtifactService/CreateArtifact`，**请求根本没到服务端**——服务端日志里连一条都没有）。挂包脚本本身在本地验过：挂上 + 再挂一遍跳过（幂等 ✓）。
 
 最后更新：批次 271 ①（agent a）——**i18n 基建（注入层·字典+切换+跟随）**（用户拍板的发布级需求：界面中英混杂要做成完整 zh/en 国际化，且**不能改 `public/`**——「一模一样」基线与差分测试都要保住，所以走**注入层**：服务端 static 响应对 `text/html` 注入运行时脚本，桌面壳与 Web 版同一个口子两边覆盖）：
 ①**字典与运行时**：`i18n_dict.json`（`{原文:{zh,en}}` 11 条种子词条·en≠原文防振荡）+ `i18n_runtime.js`（IIFE·`JSON.parse("@@DICT@@")` 占位**字符串字面量**形态——正文带引号或 `${` 都弄不坏注入脚本·语言链 `localStorage.owb-lang → navigator.language zh*→zh 否则 en → 兜底 zh`·文本节点按 **trim 后整串匹配**保首尾空白·扫 title/placeholder/aria-label 三属性·**MutationObserver 50ms 防抖**——前端全是 JS 动态渲染只扫初始 HTML 没用·未命中回退原文）。