fix(stream): retry mid-assembly chunk timeouts instead of halting

[yogthos]

Closes #545.

Problem

When a provider stalled while a tool call was mid-assembly, the stream-chunk timeout fired as a hard error and the run halted (Once I see the error, everything halts, essentially.). A retry layer already existed, but it never engaged: any thinking/text delta streamed before the tool call marked the attempt committed, and the retry layer refused to replay a committed attempt. For reasoning models (e.g. ChatGPT-5.5) that emit thinking before a tool call, a single stall was fatal.

All of the recovery machinery was already in place — the consumer discards the partial assistant message on StreamEvent::Retry (PROV-5) and shows a retry banner. The only thing blocking recovery was the if !committed guard.

Changes

• src/agent/agent_loop/retry.rs — retry timeout errors even after content has committed. The partial is stalled/incomplete, so discarding it on Retry and restarting is correct. Non-timeout committed errors (hard resets, auth) still surface to avoid duplicating tokens already shown.
• src/timeout.rs — DEFAULT_TOOL_CALL_GAP_SECS 30 → 60. 30s was too tight for reasoning models behind proxies.
• src/agent/agent_loop/rig_stream.rs — the mid-assembly error now states it is retried automatically and names timeouts.tool_call_gap_secs.
• docs/config.md — updated default + note that this timeout is auto-retried.

Verification

• New test retries_timeout_after_content_committed (TDD: red → green).
• Existing does_not_retry_after_content_committed (connection reset) stays green by design — only timeouts carve out the committed guard.
• Modules green: agent_loop 523, recovery 33, retry 13, rig_stream 23, timeout 5.
• cargo clippy --bin dirge and cargo fmt --check clean.

On retry exhaustion (5 attempts) the error still surfaces cleanly via TurnEnd and returns to idle — worst case is a recoverable prompt, not a freeze.