fix(guardrail): 输入上限与附件注入预算统一换算（多附件不再被拦）

- 残留缺口：护栏量整段装配请求（字符），注入预算是单份 ⇒ 1M 窗口下 2×349525 就顶到旧上限 699050、5 份必被拦。根因是两套换算（上限按 1char=1token，注入按 loop 的 4char=1token）。

- 修法：上限 = max(262144, 推导预算 tokens × loop.CharsPerToken) ⇒ 1M 窗口 2,796,200 字符（5 份满额注入 1,747,625 有余量）；不变量升级为「N 份」（maxChatDocumentsPerTurn=5，带出处注释）；WARN 文案升级为多附件口径（max_documents/document_inject_chars/document_inject_total_chars/guardrail_max_input_chars/hint）。

- 同一换算常量复用：在 loop/compactor.go 的既有无导出常量旁加导出别名 loop.CharsPerToken = charsPerToken（2 行、零行为改动、不重命名）—— 这是本切片唯一触及「不要碰」清单的改动，已由主会话复核接受（替代方案是复制一个字面量 4，会重新造出两套换算）。

- 同步陈旧注释（config/guardrail.go、wire_runtime.go 里的旧公式）与 .env.example（新公式 + 多附件口径 + 1M 算例 2796200/1747625），并有「模板 ↔ 代码现算值」的一致性用例。

- 主会话独立验收：隔离 worktree（G2b 的 7 文件，排除 B1/ST1 在途）build/vet 绿、全树 59 包 0 FAIL、护栏用例 17 PASS、双平台交叉编译绿。

- 残留（未修，需裁决）：预算关闭或落在 (0,81920) token 的部署，派生态上限 = 262144 而 5×64K = 327680 ⇒ 满载附件回合仍可能被拦（启动会记 WARN，不静默）；真正的下限应取 max(262144, maxDocs×每份注入)。

internal/runtime/loop/compactor.go

@@ -46,9 +46,18 @@ const (
 	// imageTokens 是单个图像部件的粗略 token 计数。
 	imageTokens = 1000
 
-	// charsPerToken 是离线估算使用的字符到 token 除数。
+	// charsPerToken 是离线估算使用的字符到 token 除数。附件注入预算
+	// （DocumentInjectCharsFor）与压缩估算共用它，是本仓库唯一的字符 ↔ token
+	// 换算口径。
 	charsPerToken = 4
 
+	// CharsPerToken 是 charsPerToken 的**导出别名**：组合根里按同一口径换算的
+	// 地方（cmd/cyrene 的输入护栏上限推导：上限 = 推导预算 token 数 × 本常量）
+	// 必须复用这一处定义，而不是另写一个字面量 4 —— 护栏上限与附件注入预算
+	// 曾因两边各写一套换算（1 char = 1 token vs 4 char = 1 token）而对不上，
+	// 表现是「2 份各自撞满注入预算的附件就被整回合拦死」（切片 G2b）。
+	CharsPerToken = charsPerToken
+
 	// summarySampleChars 限制被抽样进朴素摘要的每条消息文本长度。
 	summarySampleChars = 120
 )