fix(sdk): count recovered tool calls once in the limits guard

[matej21]

Summary

Count an unfinished tool call once in the limits guard, even when session recovery emits another tool_started for the same ID.

An application exercising repeated process recovery exposed a false loop detection: one interrupted shell call was started four times with the same tool call ID. The reducer counted every start as new work, so the next inference paused the agent with Repeated identical tool call detected (4 times).

Changes

• Track the counted unfinished tool call ID per agent. Tool execution is serial within an agent, so this needs one optional ID rather than a growing history.
• Ignore repeated starts of that unfinished ID for both the cumulative tool-call limit and repeated-call fingerprint history.
• Clear the marker on completion or failure. Distinct completed calls with identical arguments still trigger the loop guard.
• Preserve the marker through restart/replay; do not change event formats or execution recovery.

This does not automatically resume already-paused agents or repair counters in existing snapshots. A snapshot written before this change has no marker, so its first recovered start can still add one count; subsequent recoveries are deduplicated.

Verification

• Regression test reproduced the original bug before the fix: expected one call, observed four.
• Tests cover repeated restart/replay, actual repeated completed calls still reaching the hard limit, and failure accounting/marker cleanup.
• bun test packages/sdk/src: 1505 passed, 76 skipped, 0 failed.
• bun run ts:build: passed.
• bun run lint: passed.