fix(runtime): resume rejects provably-undispatched tools as dangling state

`deriveRejectionReasons` in `packages/runtime/src/runtime-resume.ts:1437` maps ten distinct diagnostic codes onto a single rejection reason:

```ts
case 'pending_tool_result': // indeterminate — the tool may have run and had effects
case 'tool_not_dispatched': // proven never dispatched — no effects are possible
case 'tool_recovery_corruption':
// ... seven more
reasons.add('dangling_tool_state');
```

`resolveRuntimeRecovery` goes to real trouble to separate `indeterminate` from `definitely_not_dispatched`, because the second one is provably safe to replay. That distinction is then discarded one layer up: both park the run, and both show the user the same message — "上次工具执行中断，记录已保留，暂时不能自动继续" — which is simply untrue for a tool that never started.

Being conservative about an undispatched tool may well be intentional, since it means the turn is incomplete. If so it still needs its own reason and its own message, rather than sharing them with the most dangerous case.

Scope: give `tool_not_dispatched` a distinct `ResumeRejectionReason` and copy entry, and decide deliberately whether it should block replay at all. Contained to `runtime-resume.ts` and `runtime-resume-copy.ts`, with existing recovery tests to build on.

简体中文

`deriveRejectionReasons`（`packages/runtime/src/runtime-resume.ts:1437`）把十个不同的 diagnostic code 映射到同一个拒绝原因 `dangling_tool_state`，其中 `pending_tool_result`（不确定，工具可能已执行并产生副作用）和 `tool_not_dispatched`（可证明从未派发，不可能有副作用）被同等对待。

`resolveRuntimeRecovery` 费了很大力气把 `indeterminate` 和 `definitely_not_dispatched` 分开，因为后者可以安全重放。这个区分在上一层被丢掉：两者都 park，且对用户显示同一句「上次工具执行中断，记录已保留，暂时不能自动继续」—— 对一个从未启动的工具来说这句话不成立。

对未派发的工具保守处理也许是有意的（它意味着 turn 不完整）。即便如此，它也应该有自己的 reason 和自己的文案，而不是和最危险的情况共用。

范围：给 `tool_not_dispatched` 独立的 `ResumeRejectionReason` 和文案，并明确决定它到底该不该阻断重放。改动限于 `runtime-resume.ts` 和 `runtime-resume-copy.ts`，有现成的恢复测试可依。