What does this PR do?

Stops the agent loop from exiting with iteration budget remaining when an upstream connection drops mid-stream. Fixes the misclassification described in #30963 where a partial-stream recovery stub was reported as text_response(finish_reason=stop) and the loop terminated even though the goal-judge verdict came back as continue milliseconds later.

The recovery stub returned by chat_completion_helpers.interruptible_streaming_api_call already carries a distinct id (partial-stream-stub), so two surgical fixes are enough:

1. Stub finish_reason (agent/chat_completion_helpers.py) — text-only partial → finish_reason="length" so the existing length-continuation path (3 retries, partial parts merged into final_response) fires automatically. Mid-tool-call partials keep finish_reason="stop" on purpose: their user-facing warning ("Ask me to retry if you want to continue") asks the user to drive the retry, not the agent.

2. Truthful continuation prompt (agent/conversation_loop.py) — when the response id is partial-stream-stub, swap the "[System: your response was truncated by the output length limit…]" prompt for a network-error variant ("[System: cut off by a network error mid-stream…]"). Real length truncations still see the original wording. Lying to the model leads to no-op responses ("I wasn't truncated, I'm done") that defeat the continuation.

#5544's "no duplicate message" contract is preserved verbatim — the partial content is reused, never re-emitted as a fresh API call, so the user never sees two copies of the same delta.

Related Issue

Fixes #30963

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/chat_completion_helpers.py — split the partial-stream stub into two branches: text-only emits finish_reason="length", mid-tool-call keeps "stop". Logging line updated to match.
• agent/conversation_loop.py — length-handler vprint and continuation prompt now branch on response.id == "partial-stream-stub" to use the network-error wording.
• tests/run_agent/test_partial_stream_finish_reason.py — 6 new tests locking in: stub finish_reason for both branches, prompt-branching truth-table, and an end-to-end run_conversation integration that drives a stub + continuation pair and verifies the loop makes the second API call (not exits) with the network-error prompt reaching the model.

Backwards compatible: the public stub shape is unchanged (still id="partial-stream-stub"), no config keys added, no schema changes. Real finish_reason="length" responses keep the existing prompt and behaviour.

How to Test

# New regression tests (6 tests, ~3s)
./scripts/run_tests.sh tests/run_agent/test_partial_stream_finish_reason.py

# Adjacent suites (streaming infra + run_agent integration), no regressions
./scripts/run_tests.sh tests/run_agent/test_streaming.py \
    tests/run_agent/test_stream_interrupt_retry.py \
    tests/run_agent/test_partial_stream_finish_reason.py \
    tests/run_agent/test_run_agent.py
# expected: all passing (test_run_agent.py has pre-existing sandbox-permission
# failures on darwin 24.6.0 — confirmed unchanged on upstream/main with
# 42 failed, 35 passed, 262 errors before AND after this PR)

End-to-end behaviour after the fix (mirrors the user's #30963 log):

WARNING agent.chat_completion_helpers:
  Partial stream delivered before error; returning length-truncated stub
  with 109 chars of recovered content so the loop can continue from where
  the stream died: peer closed connection without sending complete
  message body (incomplete chunked read)

⚠️  Stream interrupted by network error
   (finish_reason='length' on partial-stream-stub)
↻ Stream interrupted — requesting continuation (1/3)...

[next API call sent with the network-error continuation prompt;
 model resumes from the cut point, finish_reason=stop, loop continues
 to tool execution / goal eval — no more premature exit]

Before: loop exited with text_response(finish_reason=stop) and 228/9999 budget unused, goal verdict continue arrived too late to do anything. After: loop persists the partial assistant content, asks the model to continue, and keeps making progress against the goal — bounded by the existing length_continue_retries=3 cap so a persistently dead provider still surfaces as a clean partial after 3 attempts.

Checklist

• Conventional Commits (fix(streaming):, fix(conversation-loop):, test(streaming):)
• 3 focused commits, single author
• 6 new tests pass; adjacent streaming + run_agent suites pass; pre-existing unrelated failures on test_run_agent.py confirmed unchanged on upstream/main
• Tested on macOS 15.6 (darwin 24.6.0), Python 3.12.5
• No new config keys, no schema migration, no platform-specific calls
• #5544 "no duplicate streamed message" contract preserved (stub still reuses delivered content rather than re-emitting)

Infographic