feat(t152): workers_ai_chat 種子（auth: binding，免金鑰）＋ 修 /init/seed 吃掉 3.12 欄位＋ 修 D1 LIKE 長查詢 500

SDD: workflow-discovery 3.12/3.13（不是新規格；3.12 已 confirmed 並實作完成）

## 1) workers_ai_chat 種子（新）
Cloudflare Workers AI 走 env.AI binding ⇒ 用戶不必填任何 API 金鑰就能問答。
放種子表而非產品安裝器：「裝好後預設有哪些 recipe」是平台能力（rule 07 薄殼原則）。
換模型／換供應商＝改這一筆 recipe，workflow 不動。

選型實測（1.4.4 實例，真實長度 RAG prompt，每個模型連跑 2 次）：
  llama-4-scout-17b        2373／2173 ms  ✅ 答案最完整、引用正確 ← 選它
  llama-3.3-70b-fp8-fast   3261／2147 ms  ✅ 可用但波動較大
  mistral-small-3.1-24b    3560／3631 ms
  qwen2.5-coder-32b        3572／3353 ms
  gpt-oss-120b             1971／2295 ms  ❌ 回應形狀不同，response 取不到文字
  gemma-3-12b-it           ❌ 5018 帳號無權限
對照舊路徑 Gemini gemma-4-31b-it：同型提問 16.87 s，且吐整段英文思考草稿。

## 2) 修 /init/seed 靜默吃掉 3.12 欄位
3.12 給 RecipeDefinition 加了 body_template/response_map/auth/binding_name，
但 /init/seed 是**列舉欄位重建** recipe record ⇒ 不在名單上的欄位被丟掉。
最惡劣的地方是「哪裡都不會紅」：recipe 查得到、endpoint 對，只有跑起來像沒設定過。
與 08-02 syncManifest 吃掉 manifest.daemon 欄同型（教訓：東西還在不在也要進機械閘）。
加 tests/init-seed-recipe-fields.test.ts：拿掉修復會紅、補回會綠（已實測會擋）。

## 3) 修 D1 LIKE pattern 50 bytes 上限造成的 500
/entries/search?q=… 只要 q 超過 48 bytes 就回 HTTP 500，沒有錯誤訊息。
逐 byte 二分：48→200／49→500；中文 16 字→200／17 字→500。
判別實驗：q 固定 48 bytes、其他 filter 全塞滿讓 SQL 變很長 → 仍 200
⇒ 爆的是 LIKE 的 pattern（'%'+q+'%' = 50），不是 statement 長度。
中文問句超過 16 字是常態，而 rag_chat 用整句問題當 q ⇒ 聊天對正常問句等於不能用。
（＝InkStoneCo status.md 待辦第 1 條「KBDB keyword 長查詢會炸」的根因。）
修法：q ≤ 48 bytes 走原路（行為逐字不變），超過才拆詞／切 UTF-8 邊界片段。
kbdb 全套 83 測全綠（含新增 8 項）。

## 4) 順手
- 移除被 commit 進 repo 的 node_modules 壞 symlink（指向 leo Mac 的絕對路徑，
  害任何 fresh clone 裝不起來、切分支還會把裝好的蓋掉——本次撞了兩次）。
- pending-changes.md 加 P2 提案（fan-out 並行執行）＋等裁決，未動引擎。

驗證：cypher-executor 新增測試 17/17 綠；tsc 與基線逐字相同；
全套測試失敗集合與基線**逐字相同**（基線 14 個失敗，本分支 t173 既有，非本次引入）。

system-dev/docs/3-specs/workflow-discovery/tasks.md

@@ -199,6 +199,17 @@
       一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）。
       **相容硬要求**：既有 recipe（無新欄位）行為完全不變。
 - [◐] 3.13 **驗收＝CP 步驟 5 考試（features/07）**
+      ◐ 08-03（t152，**3.13「真正的改寫」那半落地**）：`rag_chat` 的 `ask_llm` 從
+      「整包 Gemini 細節寫在 workflow 節點」改成 `component: workers_ai_chat`（一個 recipe 名 ＋ 一個 prompt），
+      `finalize` 從 **2786 字元縮到 12 行**（回應解讀搬進 recipe 的 `response_map`）。
+      本 repo 側配套：`api-recipe-seeds.ts` 新增 `workers_ai_chat` 種子（`auth: binding`，
+      3.12 第四型認證的第一個真實案例）＋修掉 `/init/seed` **列舉式重建吃掉 3.12 四個欄位**的洞
+      （種子帶了 body_template/response_map/auth 卻進不了 KV，且哪裡都不會紅——與 08-02
+      `syncManifest` 吃掉 `manifest.daemon` 同型）。回歸閘 `tests/init-seed-recipe-fields.test.ts`
+      3 項，**拿掉修復會紅、補回會綠**（實測過會擋）。
+      實例端到端（1.4.4 youlin 帳號，**零 API 金鑰**）：問答鏈全綠、有答案有出處。
+      選型實測見種子檔註解（llama-4-scout 2.2s vs Gemini gemma-4-31b **16.87s**）。
+      ⚠️ 仍 ◐ 未 ✅：haiku 場景（缺件時只寫 recipe 就補全、零 JS）＝features/09 stage 端到端未驗。
       ◐ 08-01：本地驗收綠（`tests/step5-acceptance.test.ts` 3 項），實跑輸出＝
       **舊寫法 1201 字元 / if×8 → 新寫法 350 字元 / if×0（下降 71%）**，
       且分流工作流 `success=true`、零 code 節點。