SessionProcessor accepts incomplete streams, replays tool turns on retry, and repeats overflow recovery

Version: dev @ 193de13a88

Symptoms (all reproducible on current dev):

1. Incomplete streams are accepted as settled. When a provider stream ends with finish other and no raw reason (or the connection just ends after a settled step), the turn is treated as complete. Expected: the turn should fail closed with a typed error so the caller/retry layer can react.
2. Retries replay turns that already had side effects. After a retryable error, the processor re-issues a request even when the attempt already executed tool calls or dispatched experimental.text.complete hooks, and stale parts/accounting of the failed attempt linger in the transcript.
3. Interruption/failure identity is lost. A cancellation landing during a retry backoff (or a cleanup write fault) surfaces as a plain error or a fake success; the original interrupt cause is not preserved for the caller.
4. Overflow recovery is unbounded. Main overflow → compaction → replayed main → overflow again triggers another compaction; there is no per-run limit, no admission check for compressible history, and no veto once the attempt already produced output.
5. A failed turn without finish restarts on loop re-entry, issuing a new provider request instead of returning the stored failure (a turn with finish: "error" correctly stops).

Expected: bounded, vetoed retry with attempt rollback; interruption-preserving cancellation; typed incomplete/length/overflow classification; one reactive recovery per prompt-loop run; failed turns stop on re-entry.

We have a PR ready with regression coverage for each case — will link it as soon as the issue number exists.