[llm] 清理与文档：死代码、不可达回退、与行为不符的注释 #94

🤖 本 issue 由审阅 agent 手动提交（File agent issue workflow 尚未进入 main），结论未经维护者核实，不代表维护者判断。

本 issue 是清理项，不是缺陷。四处独立的小问题合并。

1 parse_json_array 的第二条回退不可达

// crates/soul-mem-llm/src/json.rs:229-231
let candidate = extract_balanced_array(&without_think)
    .or_else(|| extract_balanced_array(&strip_markdown_fences(&without_think)));

strip_markdown_fences 只删除以 ``` 开头的整行，从不移动或删除第一个 [，因此第二次调用与第一次扫描的是同一个起点、结果必然相同（无围栏时函数还直接原样返回）。这条回退声明了一条无法生效的恢复路径。

建议：删除该 or_else，或说明它究竟想覆盖哪种输入并补一个能触发的测试。

2 extract_json_array 是遗留陷阱 API

// crates/soul-mem-llm/src/json.rs:84-92
/// 取第一个 `[` 到最后一个 `]` 之间的片段。
/// **不感知嵌套与字符串**，只在内容确定是单个数组时可用
pub fn extract_json_array(text: &str) -> Option<&str>

parse_json_array 已经统一走平衡括号版，但该函数仍是 pub。文档里明确记录过它的历史缺陷（尾部解释里出现 } 就解析失败，见 json.rs:12-16），留着容易再被误用。

建议：删除，或标 #[deprecated] 并把文档改成「不要在新代码中使用」。

3 strip_markdown_fences 的文档与行为不符，且有一个冗余条件

// crates/soul-mem-llm/src/json.rs:204-222
/// 没有围栏时原样返回（只做 trim），不做任何猜测性改写。
pub fn strip_markdown_fences(text: &str) -> String {
    ...
    if stripped || in_fence {
        result.join("\n").trim().to_string()
    } else {
        text.to_string()      // ← 无围栏时不做 trim，与文档的「只做 trim」相反
    }
}

• in_fence 在 stripped == false 时不可能为真（两者都由同一批 ``` 行设置），|| in_fence 是冗余的；
• 有围栏时结果被 trim()，无围栏时原样返回，行为不对称，而文档说的是「只做 trim」。测试 strip_markdown_fences_leaves_plain_text_untouched 固化了现状。

建议：统一 trim 语义（或修正文档），并删掉冗余条件。

4 begin() 里的 let _ = task; 是死代码

// crates/soul-mem-llm/src/engine.rs:143-158
fn begin(&self, task: &Task, streaming: bool) -> Arc<CallCtx> {
    ...
    let _ = task;     // ← prompt 刻意不入观测，但这一行没有表达出这个意图
    call
}

它看起来像「task 被用到了」，实际只是吞掉未使用变量的告警。

建议：删掉该行并把参数改名为 _task，或加一行注释说明「prompt 文本刻意不进入观测事件」（后者更有价值，因为这是本 crate 的一条不变量）。

位置

• crates/soul-mem-llm/src/json.rs:84-92, 204-222, 229-231
• crates/soul-mem-llm/src/engine.rs:143-159

环境

分支 dev（efaf5cb）；仅静态分析——沙箱为只读，未运行 cargo。