fix(cypher-executor): /cypher/search 不再誤報執行期原生零件 not_found（Arcrun#88）

病因：/cypher/search 只查 component registry（SUBMISSIONS_KV，經 submitComponent/
index-only 才有記錄）；而 component-loader.ts 能直接解析、從不查 registry 的一整類
零件（trigger_workflow／BUILTIN_COMPONENTS／LOGIC_BINDING_MAP／WASM_HTTP_RUNNER_IDS，
如 if_control／http_request／switch）從未被 submit 過。leo21c 實例實測：
GET /components/catalog 回 404「零件 catalog 不存在」，search 因此對這些零件誠實地
回「兩庫都查過沒有」——但它們其實跑得動（leo 08-11 探測工作流已證）。

修法：從 component-loader.ts 匯出 RUNTIME_NATIVE_COMPONENT_IDS（既有三份執行期
解析白名單的聯集，非新清單），search-nodes.ts 在查 registry 之前先比對，
不受 registry 是否可達／是否已 backfill 影響。真正不存在的零件仍誠實回
not_found／unknown，not_found 的分型建議與相似候選機制不變。

刻意不做：不掃描 registry/components/* 目錄當清單來源——那含已標記待刪的死碼
（km_writer／kbdb_upsert_block），07-30 曾把這類死碼誤灌進 registry；也不投資
SUBMISSIONS_KV 的 backfill 腳本——decisions-summary.md D29 已定調 SUBMISSIONS_KV
併入「KV 退休戰」，不宜再加投資。

測試：cypher-executor/tests/search-nodes-runtime-native.test.ts 7 case 全綠，
複現 registry unreachable／registry 可達但目錄空（leo21c 實例的真實症狀）兩種情境。
全 suite 迴歸：357 pass（較修前 350 pass 多 7 個新測試），既有 14 個失敗與修前
數量、內容完全相同（pre-existing，與本次改動無關）。

cypher-executor/src/actions/search-nodes.ts

@@ -1,6 +1,6 @@
 import type { ParsedTriplets, NodeRole } from './triplet-parser';
 import { resolveNodeRole, isVirtualIoName } from './triplet-parser';
-import { wasmWorkerUrl } from '../lib/component-loader';
+import { wasmWorkerUrl, RUNTIME_NATIVE_COMPONENT_IDS } from '../lib/component-loader';
 import { resolveRecipe } from '../routes/recipes';
 import type { RecipeDefinition } from '../routes/recipes';
 import { branchHintFor } from '../lib/branch-hints';
@@ -44,8 +44,12 @@ export type NodeInfo = {
   status: NodeStatus;
   componentId?: string;
   type: NodeRole;
-  /** found 時標來源庫：零件 registry（component）或 recipe 庫（recipe）。 */
-  source?: 'component' | 'recipe';
+  /**
+   * found 時標來源庫：零件 registry（component）、recipe 庫（recipe），
+   * 或 cypher-executor 自帶、無須查 registry 即保證解析得動的執行期原生零件（builtin，
+   * Arcrun#88——component-loader.ts 的 RUNTIME_NATIVE_COMPONENT_IDS）。
+   */
+  source?: 'component' | 'recipe' | 'builtin';
   /** 零件契約（found 時附上，讓 AI 知道怎麼填 payload）。 */
   input_schema?: unknown;
   /** 成功率（found 時附上，讓「被測過幾次」看得見）。 */
@@ -212,6 +216,25 @@ export async function searchNodes(
       continue;
     }
 
+    // ── 執行期原生零件（Arcrun#88）：查 registry 之前先比對 ──────────────────
+    // component-loader.ts 的 RUNTIME_NATIVE_COMPONENT_IDS＝trigger_workflow／
+    // BUILTIN_COMPONENTS／LOGIC_BINDING_MAP／WASM_HTTP_RUNNER_IDS 的聯集——
+    // 這些零件 cypher-executor 自己就能 resolve，從不查 registry，執行期保證解析得動。
+    // 病史：registry 是空的／未部署新版 `/catalog` 端點時，這批零件（if_control／
+    // http_request／switch…）會被下面「兩庫都查過沒有」誤判成 not_found——
+    // 而 leo 08-11 實測探測工作流證明它們跑得動。命中即 found，不受 registry 健康狀態影響。
+    // target=recipe（使用者明確只要查 recipe 庫）不適用——這些從來不是 recipe。
+    if (wantComponents && RUNTIME_NATIVE_COMPONENT_IDS.has(componentId)) {
+      nodeResults[nodeName] = {
+        status: 'found',
+        componentId,
+        type: role,
+        source: 'builtin',
+        branch_hint: branchHintFor(componentId),
+      };
+      continue;
+    }
+
     // registry 完全查不通（未部署／網路失敗）⇒ 誠實回 unknown。
     // **不能誤判 not_found**——那會讓 AI 以為零件不存在而重寫 code，正是要避免的事。
     // 舊 registry 沒有 /catalog 端點（no_endpoint）→ 退回逐顆查（相容路徑）。