feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链

第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。

## 为什么是这三个

按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。

## 关键设计：包内符号链接，不链接静态库、不 include 包外源

三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：

1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
   - .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
     而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
     实测报 `cannot find .../libha_codec.a`
   - 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
     被链进目标产物，实测报 `file in wrong format`

2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
   ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
   7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
   文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
   （包内 shim `#include` 包外源同样漏跟踪，已实测排除。）

3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
   文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
   也不需要「同步 C 源」的 make 目标。

## 不需要额外 build tag

ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。

## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）

- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
  `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
  （deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
  COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
  平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）

## 验证（每条可复现）

- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL

新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。

## 文档

- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
  「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据

internal/agent/api/codec_pure.go

@@ -0,0 +1,103 @@
+package api
+
+// codec_pure.go —— 编解码层的**纯 Go 实现**，永远参与编译。
+//
+// 它有两个身份：
+//   1. CGO_ENABLED=0 时的生产实现（Windows 包走这里，见
+//      deploy/packaging/package-windows.sh:69）
+//   2. CGO_ENABLED=1 时**黄金对照的基准**（codec_golden_test.go 用同一组输入
+//      对比它与 C 实现，逐值必须相等）
+//
+// 因此本文件**不带 build tag**——两条路径都要能见到它。
+
+import "strings"
+
+// defaultInferredContextWindow 是模型名无法推断窗口时的兜底。
+//
+// 32768 是个保守值，但它属于**静默降级**：模型名写 AUTO（网关自己选上游）时
+// 匹配不到任何分支，内核就会拿着一份比真实小得多的窗口去算全部预算
+// （实测：deepseek-v4.1-flash 能吞 990,034 token，而预算按 32768 算）。
+// 兜底值本身不猜大：猜大会让请求直接撞上游 400。
+const defaultInferredContextWindow = 32768
+
+// contextWindowUnknown 是「模型名推断不出窗口」的哨兵值。
+//
+// 与 C 侧 HA_CODEC_CONTEXT_WINDOW_UNKNOWN 取值必须一致。
+// 用哨兵而非直接返回兜底值：调用方要能区分「真推断出了」与
+// 「推断不出、只能兜底」——后者必须记日志，让窗口被低估这件事可见。
+const contextWindowUnknown = -1
+
+// modelContextWindowPure 由模型名推断最大上下文窗口；推断不出返回哨兵。
+// 标称窗口 ≠ 有效窗口：接近满时注意力涣散，调用方应取 70-80% 为目标利用率。
+func modelContextWindowPure(model string) int {
+	model = strings.ToLower(model)
+	switch {
+	case strings.Contains(model, "deepseek-v4") || strings.Contains(model, "deepseek-v3"):
+		return 1048576
+	case strings.Contains(model, "deepseek-r1") || strings.Contains(model, "deepseek-chat"):
+		return 65536
+	case strings.Contains(model, "gpt-4") && (strings.Contains(model, "turbo") || strings.Contains(model, "mini") || strings.Contains(model, "omni")):
+		return 128000
+	case strings.Contains(model, "gpt-4"):
+		return 8192
+	case strings.Contains(model, "gpt-3.5"):
+		return 16384
+	case strings.Contains(model, "claude-3.5") || strings.Contains(model, "claude-3"):
+		return 200000
+	case strings.Contains(model, "claude"):
+		return 100000
+	case strings.Contains(model, "gemini-1.5") || strings.Contains(model, "gemini-2"):
+		return 1048576
+	case strings.Contains(model, "gemini"):
+		return 32768
+	case strings.Contains(model, "qwen"):
+		return 131072
+	case strings.Contains(model, "glm") || strings.Contains(model, "chatglm"):
+		return 131072
+	case strings.Contains(model, "llama-3"):
+		return 8192
+	case strings.Contains(model, "llama-2"):
+		return 4096
+	case strings.Contains(model, "mistral") || strings.Contains(model, "mixtral"):
+		return 32768
+	case strings.Contains(model, "yi-") || strings.Contains(model, "零一"):
+		return 200000
+	case strings.Contains(model, "moonshot") || strings.Contains(model, "kimi"):
+		return 131072
+	default:
+		return contextWindowUnknown
+	}
+}
+
+// estimateTokensPure 粗略估算 token 数。
+// 中文 ~1.5 token/字，英文 ~0.3 token/字符，保守估计取 max(1, runeCount * 2)。
+func estimateTokensPure(text string) int {
+	if text == "" {
+		return 0
+	}
+	runeCount := len([]rune(text))
+	if runeCount == 0 {
+		return 0
+	}
+	t := runeCount * 2
+	if t < 1 {
+		return 1
+	}
+	return t
+}
+
+// truncateByTokensPure 截断字符串至不超过 maxTokens 估计值。
+func truncateByTokensPure(s string, maxTokens int) string {
+	if maxTokens <= 0 || s == "" {
+		return ""
+	}
+	runes := []rune(s)
+	if len(runes)*2 <= maxTokens {
+		return s
+	}
+	keep := maxTokens / 2
+	if keep >= len(runes) {
+		return s
+	}
+	return string(runes[:keep])
+}