perf: bound graph-memory recall token injection

[Liyuk]

动机

graph-memory:recall 上下文在每轮 prompt 组装时都会注入。现有实现里有几处「无上限」的输入，让它随图谱规模线性膨胀：

1. tokenBudget 是死参数：dsh.ts / index.ts 写死 tokenBudget: 0，assembleContext 收了参数却全量放入、不裁剪。
2. 节点 content 全文塞入，且首行重复节点 name（XML 标签已有 name= 属性，首行纯冗余）。
3. 精确 + 泛化两条召回路径各自跑满 limit，合并只去重 → 节点数翻倍（12 而非 6）。
4. episodic 溯源拉 top-3 节点 × 2 session × 500 字符，无必要地长。
5. 系统提示模板 + 每节点 updated 时间戳冗长。

改动

• assemble.ts
  • 真正执行 tokenBudget（贪心裁剪，最高优先级先保留，至少保留 1 个节点）
  • 去掉 content 首行重复的 name 行（stripLeadingName）
  • content 按 contentMaxChars（默认 400）截断，附省略号
  • episodic 收紧为 top-2 × 300 字符 × 150 字符/条
  • 移除 updated 时间戳、精简系统提示模板
• recall.ts：精确路径优先，泛化路径只回填精确路径未覆盖的社区，总量封顶 recallMaxNodes
• types.ts + dsh.ts + index.ts：通过 config 接线 recallTokenBudget（默认 2000）与 contentMaxChars（默认 400）；传 0 = 不限制（向后兼容）

实测

在真实 897 节点、923 边、250 社区的图谱上跑 5 条查询：

指标	优化前	优化后
召回节点/query	12	6
注入 token/query（平均）	2781	1424
节省		~49%

召回质量不降：完整节点 content 仍可通过 gm_search 按需取回。

兼容性

• 所有新行为通过 config 暴露，默认值保守；tokenBudget / contentMaxChars 传 0 即回到旧行为。
• 新增/更新测试覆盖裁剪、首行去重、截断、双路径配额，全量测试通过。