fix(engine): 回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92）

真因：零件（main.go）給 host function 的接收緩衝區是固定大小（http_request 64KB、
claude_api 1MB）。回應超過這個大小時，wasi-shim 的 writeOut 照寫不誤：

    new Uint8Array(buf, outPtr, data.length).set(data)

data 比零件的 outBuf 大 → 覆寫零件堆積體，零件接著 outBuf[:outLen] 切片 panic；
或 writeOut 撞 memory 邊界丟例外 → 回 1 → 零件印一句 "HTTP request failed"。
使用者照那句去查連線／URL／防火牆，方向全錯。

修法（容量握手，不改 host function 簽名、向後相容）：
- 零件呼叫前把 outBuf 長度預先寫進 *outLenPtr（宣告容量）
- host 在寫回前讀這個值當上限；塞不下就**不寫**（不再覆寫零件記憶體），回新的
  HOST_TOO_LARGE=3
- http_request host fn 收到 3 → 改寫一段講真話的 error envelope（實際大小＋上限＋
  「不是連線失敗」＋分頁/篩選的具體做法＋機器可讀 code/actual_bytes/limit_bytes），
  沿用既有 parsed["error"] 判定鏈原樣送到使用者面前
- 舊零件沒宣告容量（讀到 0）→ 維持舊行為。不可硬套 64KB 預設：各零件緩衝區大小不同，
  硬套會把原本正常的大回應誤判成「太大」，那只是換一種說謊

同一條路徑上另一個「訊息與真因脫節」一併修：component-loader 的 makeHttpRunner
`try res.json() catch res.text()`，在零件回非 JSON 時 body 已被消費 → 丟
"Body has already been used"，與真因無關（同檔 readBodyOnce 的註解早就寫明這個坑）。
改成只讀一次。

驗證狀態（誠實標示，mindset §7）：
- 通：5 顆零件 tinygo build 全過，wasm 已重編進 .component-builds/
  （claude_api 依 .gitignore 慣例不入庫，由部署端重編）
- 未跑：runtime 驗證。本 session 的權限層擋掉 node/vitest/wasmtime，
  before/after 實測輸出待人跑 scripts/repro-oversize-response.mjs
- 未做：.worker-builds/ 重編（需 node scripts/build-worker-artifacts.mjs），
  否則修法不會進 self-hosted 安裝路徑（Arcrun#93 同款陷阱）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

registry/components/http_request/main.go

@@ -9,9 +9,14 @@ import (
 	"encoding/json"
 	"io"
 	"os"
+	"strconv"
 	"unsafe"
 )
 
+// host function 回傳碼，與 cypher-executor/src/lib/wasi-shim.ts 的 HOST_* 同一組數字。
+// 3 = 資料塞不進零件宣告的接收緩衝區（Arcrun#92：以前這種情況會被說成 "HTTP request failed"）
+const hostTooLarge uint32 = 3
+
 // host function 宣告（由 WASI shim 注入）
 //
 //go:wasmimport u6u http_request
@@ -86,7 +91,11 @@ func main() {
 	headersBytes := []byte(headersJSON)
 	bodyBytes := []byte(bodyStr)
 	outBuf := make([]byte, 65536) // 64KB output buffer
-	var outLen uint32
+	// 容量握手（Arcrun#92）：呼叫前先把緩衝區大小告訴 host。
+	// host（cypher-executor/src/lib/wasi-shim.ts 的 writeOut）拿這個值當上限——
+	// 塞不下時不會硬寫爆這塊記憶體，而是改寫一段「回應太大 + 實際/上限大小 + 該怎麼辦」
+	// 的 error envelope 回來，由下面既有的 parsed["error"] 判定鏈原樣交給使用者。
+	outLen := uint32(len(outBuf))
 
 	urlPtr, urlLen := safePtr(urlBytes)
 	methodPtr, methodLen := safePtr(methodBytes)
@@ -101,8 +110,18 @@ func main() {
 		uintptr(unsafe.Pointer(&outBuf[0])), uintptr(unsafe.Pointer(&outLen)),
 	)
 
+	// host function 回傳碼（定義在 wasi-shim.ts）：0=成功 1=host 端錯誤 3=回應塞不下緩衝區
+	if result == hostTooLarge {
+		// 走到這裡＝連「回應太大」的說明本身都塞不進緩衝區（極端情況），
+		// 所以零件自己講。訊息一樣要講清楚真因，不能退回 "HTTP request failed"。
+		writeError("回應太大，裝不下：對方的回應超過這個零件單次能接收的 64 KB 上限。" +
+			"這不是連線失敗，資料也沒有被截掉一半。" +
+			"做法：用來源 API 的分頁或篩選參數（例如 limit / page / per_page / fields）把回應縮小再重試。")
+		return
+	}
 	if result != 0 {
-		writeError("HTTP request failed")
+		writeError("沒有拿到回應：引擎的 host function 回傳錯誤碼 " + strconv.Itoa(int(result)) +
+			"（0=成功 1=引擎端錯誤 3=回應太大）。這是引擎側的問題，不是你的 workflow 參數寫錯。")
 		return
 	}