Resumed sessions handle unresolved and interrupted tool calls via answeredToolUseIds

What

• A new function synthesizes fabricated tool_result blocks (marked with toolDenialKind: "interrupted") for tool_use calls that were left unresolved when a session was interrupted, tracked via a new outTrailingUnresolvedToolUseIds set. These are surfaced through a new answeredToolUseIds field returned from the resume-message-building pipeline and threaded through to the headless runner.
• Session state serialization now carries this answeredToolUseIds field alongside the existing supersededToolUseIds/supersededToolNames fields in several places.
• When resuming after an interrupted turn, every id in answeredToolUseIds is now also added to the set of tool-use ids treated as already-answered, so they won't be re-prompted (previously only ids from the resumed-turn tool list and a currently-parked permission were included).

Why Without this, resuming a session after an interruption could leave tool calls dangling with no result, or could re-prompt for permissions that were already effectively resolved. Tracking answeredToolUseIds end to end keeps resumed conversations consistent with what actually happened before the interruption.