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

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

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.