deepagents 版本漂移：本机 venv 0.7.13 vs 仓库 compat pin 0.7.6，ensure_sandbox_compat 抛异常

## 本机 venv 的 deepagents 与仓库 compat pin 不一致

**实测（#3403 排查途中的旁证，实测 SHA `4fd35a9ff`）**：

- 本机 venv 装的是 **deepagents 0.7.13**
- 仓库的 compat pin 写的是 **0.7.6**
- `ensure_sandbox_compat()` 因此**直接抛异常**

排查方当时只在**进程内旁路**了它以便测量，**没有改仓库的 pin**（做法正确）。但这是一次真实的环境漂移，值得单独看。

## 要判定的

1. **漂移从哪来**：是谁把 0.7.13 装进去的？`uv sync` 的解析结果与 `uv.lock` 是否一致？`uv.lock` 本身有没有被更新过？
2. **`ensure_sandbox_compat()` 抛异常时，实际后果是什么**：是整个 deep-agent-service 起不来，还是某条路径降级？**如果它在生产上会抛，那是 P0；如果只在本机装错时抛，那是开发体验问题。** 先分清。
3. **这道门是在保护什么**：0.7.6 → 0.7.13 之间有没有本仓依赖的行为变化？本仓已有先例——**langgraph-api 0.12.4 的中断 run 报 success**（run 状态骗人、thread 才是 interrupted），上游小版本差异会改变可观察行为。

## 要求

- **不要简单地把 pin 提到 0.7.13 了事**——先回答第 3 条：两个版本之间本仓依赖的行为有没有变。若没查就提 pin，等于把一道门调成不会红。
- 若确认需要升级，**必须有反证**：造出「新版本行为与本仓假设不符」的形状，确认某条断言会红；没有这样的断言就补一条。
- 若确认是本机装错、生产不受影响，**如实写结论并说明怎么防止下一个人再装错**（例如让 `./init.sh` 或 `ensure_sandbox_compat` 的报错直接说出该怎么修）。

## 相关

#3403（排查途中发现）、`langgraph-api 0.12.4 中断 run 报 success` 的既有教训（上游小版本会改变可观察行为）。

Start with ensure_sandbox_compat(), init.sh, uv.lock, and the uv sync result, then trace the dependency path described in #3403. Done means identifying why 0.7.13 was installed, determining whether production is affected, and documenting the correct prevention or adding a regression assertion for any incompatible behavior.

Written by the indexing model from the issue text.