fix(guardrail): 输入护栏上限按推导预算派生（修「大附件被拦死」）+ 第 5 条 flake

- 真 bug：文档注入预算（1M 窗口 ⇒ 349525 字符）> 输入护栏硬编码上限（262144）⇒ 带 744KB 附件的 POST /chat 直接 input_length_exceeded/guardrail_input，整个回合作废（主会话活服务实测）。

- 修法：guardrailMaxInputChars → guardrailMinInputChars(256Ki 下限) + 纯函数 deriveGuardrailInputLimit(log, override, budgetTokens, docInjectChars)：派生值 = max(下限, 推导预算 tokens)（1M ⇒ 699050）；新增 env GUARDRAIL_MAX_INPUT_CHARS（未设/0=派生、>0=覆盖、<0=WARN 回落）；预算只在 wire_context 推导一次并经 buildGuardrailPipeline(ctxBudget) 传入（避免「窗口未声明」WARN 记两遍）；输出上限 65536 刻意不参与派生（有显式回归钉住）。

- 关系不变量：文档注入预算 ≤ 输入上限，人为破坏 ⇒ 一条 WARN（不静默）。

- 第 5 条 flake（exec/TestTerminal_Timeout_Killed）：仅改测试、terminal.go 保持 pristine；根因不是「杀进程失效」而是旧断言的 ~200ms 精度把宿主负载下的进程创建耗时算了进去（重压下 cmd.Start 会直接返回 deadline exceeded，红行却报 process not killed）⇒ 改为「控制组证明同命令不设短超时正常退出」的确定性证明 + 把墙钟断言降级为 10s 语义判别界（子进程自然存活期拉到 30s）。

- 主会话独立验收：隔离 worktree（G2 的 10 个文件，排除 M1 在途的 wire_channels.go）build/vet 绿、全树 59 包 0 FAIL、双平台交叉编译绿、Guardrail* 全 PASS、exec -count=20 绿；变异独立复现（把派生值退回硬编码 ⇒ 4 条红，含 budget=699050 → 262144）。

- 残留缺口（已排 G2b）：护栏量的是整段装配请求、注入预算是单份 ⇒ ≥2 份各撞注入预算的大附件仍可能被拦。

internal/runtime/exec/terminal_test.go

@@ -8,6 +8,7 @@ import (
 	"os"
 	"os/exec"
 	"path/filepath"
+	"strconv"
 	"strings"
 	"testing"
 	"time"
@@ -205,21 +206,65 @@ func TestTerminal_WorkDir_OutsideRejected(t *testing.T) {
 	}
 }
 
+// TestTerminal_Timeout_Killed 校验超时到点后**子进程真的被杀**，而不是被等到自然结束。
+//
+// 为什么不能拿「~200ms 的精度」当判据（改动前基线：三进程并行整树 2/9 红，
+// `timeout took 3.8202774s, want ~200ms (process not killed)`）：那条断言测的是
+// 「起进程 → 到点杀进程 → 收尸」的墙钟总和，而宿主重压之下**进程创建**这一段本身就
+// 能吃掉整个时限（本切片勘察实测：重压下 cmd.Start 直接返回 context deadline
+// exceeded，且已到「启动即超时」的量级），于是耗时断言退化成「宿主此刻有多忙」的
+// 代理变量 —— 红行却报「process not killed」，指向一个并不存在的生产缺陷。
+//
+// 现在按语义分两层断言，墙钟只负责区分「被杀」与「被等到自然结束」：
+//   - ① 控制组：同一个 sleep 子命令在不设短超时时**自己跑完并以 0 退出**；
+//     因此超时组那次拿到的非 nil waitErr 只可能来自「到点被杀」——这是与宿主
+//     负载无关的确定性判别，也正是本用例名字要断言的事实。
+//   - ② 超时组：Timeout 到点 ⇒ ErrTimeout，且耗时远小于子进程的自然存活期
+//     （判别界 10s ≪ 30s：宿主即便卡到秒级也不会误判成红；而「没被杀」会一路
+//     跑到 30s，落界之外必红）。
 func TestTerminal_Timeout_Killed(t *testing.T) {
 	t.Parallel()
 	requireBin(t, "sleep")
 	ex := newEnabledExecutor(t, enabledCfg("sleep", t.TempDir()))
 
-	start := time.Now()
-	_, err := ex.Execute(context.Background(), ExecRequest{
-		Command: []string{"sleep", "5"},
-		Timeout: 200 * time.Millisecond,
+	const (
+		// childSleepSeconds 是子进程的自然存活期（秒）：必须远大于任何宿主负载噪声，
+		// 「进程没被杀」才会落进判别界之外。
+		childSleepSeconds = 30
+		// killDeadline 是超时时间：远小于自然存活期，到点必须被杀。
+		killDeadline = 200 * time.Millisecond
+		// controlTimeout 是控制组的超时：只要求子命令能跑完，故留足余量。
+		controlTimeout = 30 * time.Second
+		// killProofBound 是「被杀」与「被等到自然结束」的判别界：耗时超过它，
+		// 就说明这一回合是等到了子进程自己结束，而不是被超时杀掉。
+		killProofBound = 10 * time.Second
+	)
+
+	// ① 控制组：确认这个子命令本来就以 0 正常退出，下面的推论才成立。
+	control, err := ex.Execute(context.Background(), ExecRequest{
+		Command: []string{"sleep", "0.05"},
+		Timeout: controlTimeout,
 	})
+	if err != nil {
+		t.Fatalf("控制组 Execute: %v（子命令自己都跑不完，超时组的结论便不成立）", err)
+	}
+	if control.ExitCode != 0 {
+		t.Fatalf("控制组 ExitCode = %d, want 0（sleep 正常结束本就该是 0）", control.ExitCode)
+	}
+
+	// ② 超时组：到点必须被杀，绝不等到它自己结束。
+	start := time.Now()
+	_, err = ex.Execute(context.Background(), ExecRequest{
+		Command: []string{"sleep", strconv.Itoa(childSleepSeconds)},
+		Timeout: killDeadline,
+	})
+	elapsed := time.Since(start)
 	if !errors.Is(err, ErrTimeout) {
 		t.Fatalf("err = %v, want ErrTimeout", err)
 	}
-	if elapsed := time.Since(start); elapsed > 3*time.Second {
-		t.Errorf("timeout took %v, want ~200ms (process not killed)", elapsed)
+	if elapsed >= killProofBound {
+		t.Fatalf("超时回合耗时 %v（判别界 %v，子进程自然存活期 %ds）：进程没有被杀，而是被等到了自然结束",
+			elapsed, killProofBound, childSleepSeconds)
 	}
 }