每个 run 建图都重下 56 个挂载文件 / 218 KB / 180–330ms——比 #3206 那 20 条大得多

## 现象（测量数据，来自 #3206 的排查）

PR #3217 的排查里量到一笔**比原 issue 大得多**的固定开销：

| 阶段 | 沙箱往返 | 字节 | 耗时 |
|---|---|---|---|
| **建图（每个 run 一次）** | **56** | **218 KB** | **180–330 ms** |
| 第 1 轮（同一 thread） | 21 | 88 KB | 34 ms |
| 第 2 轮（同一 thread） | 0 | 0 | 4 ms |

也就是说：**每发起一个 run，都要把 56 个挂载文件重新下一遍**（`create_native_graph` 的钉验证）。第二轮之后的对话命中 checkpoint 不再下载，但**每个新 run 都要重来**。

另有一笔本 PR 未动的：每轮往 system prompt 注入 **3230 字符 ≈ 807 token** 的技能清单，属上游 `SkillsMiddleware` 的固有开销。

## 要先回答的

1. **这 56 次往返是必须的吗？** 钉验证（binding = `sha256(sessionId + 每包 skillId/versionId/逐文件 digest)`）需要逐文件 digest，但**digest 能不能不靠重新下载全文得到**？
2. **同一会话内连续多个 run 之间能否复用？** 注意本仓刚有过教训：加缓存必须能说清失效策略，否则会出现「skill 升级了还用旧内容」——standard-web 就漂过（构建锚 1.1.2、seeder 只发 1.1.1）。既有 binding 机制是 fail-closed 的，可以作为失效判据的基础。
3. **180–330ms 在一次 run 的总时长里占比多少？** 先给数字再谈优化——#3206 的教训是，第一版简报按「0.48ms」判「不值得优化」，而真正的代价在别处（20 次 DB 事务）。

## 优先级

**不阻塞人类验收测试**，属性能优化。但它是目前量到的最大一笔固定开销，值得排期。

## 关联
#3206 / #3217（同一次排查量出）。

Start by tracing the create_native_graph path and the binding calculation described in this issue, then review the measurements from #3206 and #3217. Establish how repeated runs obtain the 56 mounted files and measure their share of total run time. Done means the reuse and invalidation requirements are documented and supported by measurements, without weakening fail-closed behavior.

Written by the indexing model from the issue text.