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×每份注入)。

cmd/cyrene/wire_runtime.go

@@ -157,9 +157,10 @@ func (a *app) wireRuntime() error {
 	// wire_context.go 一处完成。Compactor 不注入，由 loop 选用内置的结构化
 	// compactor（离线、不调模型），并按同一份注入预算估算文档部件的代价。
 	//
-	// 它必须在护栏**之前**算出来：请求侧字符上限是这份预算的函数（切片 G2：
-	// 输入上限 = max(256 Ki, 推导预算 token 数)），否则 1M 窗口下 349525 字符的
-	// 附件注入会先被硬编码的 262144 上限整回合拦死。
+	// 它必须在护栏**之前**算出来：请求侧字符上限是这份预算的函数（切片 G2/G2b：
+	// 输入上限 = max(256 Ki, 推导预算 token 数 × loop.CharsPerToken)），否则 1M 窗口下
+	// 单份 349525 字符的附件注入会先被硬编码的 262144 上限整回合拦死，多份附件更是
+	// 成倍顶到上限（G2b 把「单份」对齐成「N 份」）。
 	ctxBudget := a.contextBudget(envPath)
 
 	// 默认护栏策略在 buildGuardrailPipeline 里集中定义（敏感信息阻断 +