[BUG] [ctx: ~N%] 回复 footer 使用硬编码 200k 上下文窗口，大窗口模型固定显示 100%

cc-connect 版本：1.4.1（main 分支同样存在）

问题描述

回复尾部提示 [ctx: ~N%] 的计算使用了硬编码的 200k 上下文窗口，完全不考虑会话模型的实际上下文窗口。当模型的窗口大于 200k（如 1M 窗口的 deepseek-v4-flash[1M]）时，一旦 input_tokens 超过 200k，该指标就固定显示 ~100%，与真实占用严重不符。

位置

core/engine.go

• L16740：const modelContextWindow = 200_000 // generic fallback window for heuristic context estimates
• L16742-16751：contextIndicatorText(inputTokens int) 内 pct := inputTokens * 100 / modelContextWindow

复现

• 模型：deepseek-v4-flash[1M]（1M 上下文）
• 某一轮 input_tokens = 360527
• 计算：360527 * 100 / 200000 = 180 → 超过 100 被截断 → 显示 [ctx: ~100%]
• 实际占用约 19%（claude /context 显示 187k / 1M）

影响

任何上下文窗口不是 200k 的模型，该指标都会失真；窗口越大偏差越大，且 input 超过 200k 后恒为 100%，失去参考价值。

建议修复

调用点（约 L5557-5565，footerContext 被硬编码路径覆盖处）已经能拿到会话真实窗口 replyFooterSessionContextUsage(state.agentSession)，建议把真实 ContextWindow 传入 contextIndicatorText：

func contextIndicatorText(inputTokens, contextWindow int) string {
	if inputTokens <= 0 || contextWindow <= 0 {
		return ""
	}
	pct := inputTokens * 100 / contextWindow
	if pct > 100 {
		pct = 100
	}
	return fmt.Sprintf("[ctx: ~%d%%]", pct)
}

另外两点补充：

• event.InputTokens 是 API 上报的 input（可能含缓存命中 token），数值可能高于会话实际跟踪的上下文；可考虑优先使用 replyFooterSessionContextUsage 里的 UsedTokens。
• replyFooterContextText（L7381）已经正确使用 usage.ContextWindow，只是被 L5560 的 contextIndicatorText 硬编码路径覆盖了；修复时可以参考它。

附：真实占用 vs 指标