fix(ci): the release workflow already knew this; the new one did not. 發版流程早就知道這件事,新建的那支不知道。

Twelve tests still failed after the timeout work, all of them the three
commands backed by ryugraph's ALGO extension — `god-nodes`,
`communities`, `related`. That extension is downloaded from
extension.ryugraph.io on first use, and it is the only part of egr that
touches the network at all. On CI the download hangs: no error, no
message, just each test burning its 120s budget until the run gives up.

`publish.yml` has built that extension from source for a long time, with
the comment "fetched from an unreliable host". The knowledge existed and
was correct; it simply never reached the CI workflow added yesterday.
The same steps now run here, pinned to the same version and platform
path — change one, change both.

Third time this session the answer was already sitting in the repository
as a working control rather than something to be deduced: `doctor.test.ts`
for how to spawn the CLI, `publish.yml` for this. Cheaper to look for the
version that works than to reason about why the other one does not.

`npm run build` is now explicit rather than relying on `prepare` firing,
matching publish.yml — and the CLI tests refuse to run against a stale
`dist/`, so that reliance would have surfaced as a confusing refusal.

逾時那一輪之後仍有 12 支測試失敗,而它們全部是靠 ryugraph ALGO 擴充的那三個指令
——god-nodes、communities、related。那個擴充在第一次使用時會從
extension.ryugraph.io 下載,而它是 egr 唯一會碰到網路的部分。
在 CI 上那個下載會掛住:沒有錯誤、沒有訊息,只是每一支測試把 120 秒的預算燒完。

publish.yml 從很久以前就在從原始碼建那個擴充,註解寫著「從一個不可靠的主機取得」。
那份知識存在而且是對的,只是從來沒有到達昨天新增的那支 CI。
同樣的步驟現在也在這裡跑,版本與平台路徑與那邊一致——要改就兩處一起改。

這是本次第三次「答案本來就以一個能動的對照組躺在 repo 裡」,
而不是需要推論出來的東西:啟動 CLI 的寫法看 doctor.test.ts,這件事看 publish.yml。
**去找那個能動的版本,比推論另一個為什麼不能動便宜。**

npm run build 現在是明確的一步,不倚賴 prepare 有沒有觸發,與 publish.yml 一致——
而且 CLI 測試會拒絕對過期的 dist/ 執行,所以那個倚賴會以一個令人困惑的拒絕現形。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ssm8NLdJ2qiQttGdfvXhnS

Author: AsiaOstrich

.github/workflows/ci.yml

@@ -25,6 +25,28 @@ jobs:
       # --legacy-peer-deps 與 publish.yml 一致：不一致的安裝方式會讓
       # 「CI 綠而發版紅」變成可能，而那正是這支 workflow 要消除的落差。
       - run: npm install --legacy-peer-deps
+
+      # 🔴 ryugraph 的 ALGO 擴充是從 extension.ryugraph.io 下載的,而那個主機不可靠。
+      #    `god-nodes` / `communities` / `related` 三個指令要它,
+      #    而在 CI 上那個下載會靜靜地掛住——不是報錯,是等到測試逾時為止。
+      #    2026-09-04 首次上線後 12 支測試因此紅,而日誌裡一個網路錯誤都沒有。
+      #
+      #    ⚠️ **這一段不是新發明的**:`publish.yml` 從很久以前就在做同一件事,
+      #    註解也寫著同樣的理由。那份知識住在發版流程裡,而我建這支 CI 時沒有帶上它。
+      #    版本號 25.9.0 與路徑 linux_amd64 與那邊保持一致——**兩處要一起改**。
+      - name: Build ryugraph ALGO extension from source
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y -qq cmake
+          cd node_modules/ryugraph/ryu-source
+          make extension-release EXTENSION_LIST=algo NUM_THREADS="$(nproc)"
+          mkdir -p "$HOME/.ryu/extension/25.9.0/linux_amd64/algo"
+          cp extension/algo/build/libalgo.ryu_extension "$HOME/.ryu/extension/25.9.0/linux_amd64/algo/"
+
+      # 明確建置,不倚賴 `prepare` 有沒有觸發——publish.yml 也是這樣做的。
+      # 幾支 CLI 測試會啟動 dist/,而 `assertDistIsFresh` 會在 dist 比 src 舊時拒絕執行。
+      - run: npm run build
+
       - run: npm test
       # 錯誤訊息單一出口。self-test 先跑：一個壞掉的判別式對每個檔都回綠，
       # 而那與一次乾淨的通過在輸出上一模一樣。