fix(kbdb): 藏書地圖讀端每次都觸發重算寫 D1（Arcrun#87 止血）

liveTripletCountsByLibrary 沒有過濾 status，recomputeLibraryMap 只算
COALESCE(status,'active')='active'——兩邊判準不一致，只要庫裡有一筆
superseded triplet 就永遠判定 stale，導致每次讀地圖（GET /map、GET /map/:library、
kbdb_get_map MCP 工具）都觸發重算並新建一筆 library_map record，無止盡寫 D1，
且加劇既有的非原子 supersede 競態（kb 44 筆全 superseded、notes 兩筆同時 active
即 arcrun-rag#50 的共同根因之一）。

修法：liveTripletCountsByLibrary 的 SQL 改成 pivot 出 status 再套用與
recomputeLibraryMap 逐字一致的過濾，兩邊判準對齊。

新增迴歸測試釘住此 bug（反向驗證：跑在修前的 SQL 上會失敗，非空氣測試）；
獨立用 leo21c MCP 連線連讀兩次 kbdb_get_map() 重現修前症狀
（general 庫 updated_at 從 1786457080 前進到 1786457114，中間無寫入）。

kbdb/tests/library-map.test.ts 19/19 全綠。既有殘骸（100 筆 library_map record）
未清——目前沒有可用的 DELETE 通道，待部署後另行處理。

kbdb-sql-ok：liveTripletCountsByLibrary 的 .prepare 呼叫是牆內本體
（kbdb/src/actions/），本次 checkout 開在巢狀 worktree
matrix/arcrun/.worktree-fix-87/（避免打斷另一 session 佔用中的
matrix/arcrun 主 checkout），kbdb-api-wall-guard.sh 的字面路徑比對
*matrix/arcrun/kbdb/src/* 吃不到中間多出的 worktree 目錄層，非真的繞牆。

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

system-dev/docs/3-specs/library-map/tasks.md

@@ -44,3 +44,34 @@ leo 否決②——「**藏書地圖就是 arcrun 的最重要功能，讓 AI
 不報錯。`mcp/tests/unit/tools/kbdb-map.test.ts` 新增 1 案釘住舊謊言不再出現（18/18 全綠）。
 tsc 兩包乾淨。實測：`yuga3bse` 租戶（從未 backfill 過、真實 triplet 資料橫跨 5 個庫）改前
 `kbdb_get_map` 回 `{libraries:[],count:0}`——改動待部署後需重新實測驗證非空。
+
+### M3 止血（2026-08-11，Arcrun#87，總管交辦「動工前的量測」comment 第四節）
+
+**08-08 那次改法本身留了一個判準缺口，這次補上**：`ensureFreshLibraryMaps` 比對
+「即時三元組數」（`liveTripletCountsByLibrary`）與「快取的地圖數」（`recomputeLibraryMap`
+算出來寫進去的），但兩邊的 status 過濾不一致——`recomputeLibraryMap` 只算
+`COALESCE(status,'active')='active'`，`liveTripletCountsByLibrary` 完全不濾 status。
+只要一個庫裡混了任何一筆 superseded/deprecated triplet，兩邊數字就永遠對不上，
+`ensureFreshLibraryMaps` 就永遠判定 stale ⇒ **每次讀地圖都觸發重算，每次都新建一筆
+library_map record（superseded 舊的），無止盡寫 D1**——且加劇 `recomputeLibraryMap`
+本身非原子 supersede 的既有競態（更高重算頻率 = 更高並發重算機率），是 `kb` 庫
+全部 44 筆被標 superseded、`notes` 庫兩筆同時 active（`arcrun-rag#50`）這兩個症狀的
+共同根因之一。
+
+**修法**：`liveTripletCountsByLibrary`（`kbdb/src/actions/library-map.ts`）的 SQL 改成
+先 pivot 出每筆 triplet record 的 status，再套用與 `recomputeLibraryMap` 逐字一致的
+`COALESCE(status,'active')='active'` 過濾，兩邊判準對齊後，資料未變動時兩個計數必然相等，
+stale 判定回歸「真的有資料變動才 stale」。
+
+**驗證**：新增迴歸案「Arcrun#87 迴歸：superseded triplet 存在時，連讀兩次地圖不會再次
+觸發重算」（`kbdb/tests/library-map.test.ts`，19/19 全綠）；反向驗證過——把同一顆測試跑在
+修前的舊 SQL 上會失敗（`library_map` record 數 2 vs 期望 1），證明測試真的釘住這個 bug、
+不是空氣測試。另外用 leo21c MCP 連線（`bfezv28v`）連讀兩次 `kbdb_get_map()`（無中間寫入）
+獨立重現修前症狀：`general` 庫 `updated_at` 從 `1786457080` 前進到 `1786457114`。
+
+**尚待**：改動只在分支 `fix/library-map-recompute-loop-87-v3`（未 push、未部署 leo21c）；
+既有 100 筆 library_map 殘骸（`kb` 44 筆 superseded／`general` 41／`notes` 2）未清——
+清除需要一個目前不存在的 DELETE 通道（cypher-executor 的 `/kbdb/records/:id` proxy 只有
+GET/POST/PATCH，無 DELETE；kbdb base 自己雖有 `DELETE /records/:recordId` 但走 leo21c
+需要 `KBDB_INTERNAL_TOKEN`，非 CC 可持有的機密）——待總管部署本修法＋視情況補一支
+DELETE proxy 後再清。