Typed pending-call outcome + call correlation for long-running stdio tool calls (follow-up to #1317) #1321

Follow-up from #1317 and #1317 (comment).

#1317's fix (#1320) stops the health-check/reconnect layer from killing an in-flight stdio process just because it's slow. It doesn't add any new protocol semantics for the call itself — a timed-out call still just returns the existing timeout error, and the process stays alive for whatever comes next.

@Hronom's comment on #1317 pointed out that "process survives" and "call outcome is unambiguous" are two different problems: once a tools/call times out but the upstream is still working on it (e.g. waiting on human consent, or mid-mutation), a blind retry against the same generation is racing with a response that might still land late. Their suggestion:

• a typed waiting_human / deadline_exceeded result carrying a call id
• reject a blind retry while that call id is unresolved
• require either explicit cancellation or a fresh read-only reconciliation (e.g. list_pages) on the same connection generation before allowing another mutating call
• structured logging at timeout: {server, pid/instance_id, connection_generation, request_id, cancellation_source, resulting_state} to make it possible to tell which layer is doing what

None of this is required to close #1317 — it's a correctness/observability improvement for what happens after a timeout on a still-alive connection, not a bug fix. Worth scoping separately.