[BUG] Windows: undock (Ethernet->Wi-Fi interface swap) ends the in-flight turn with no retry, silently killing background sessions

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

On Windows, a **clean network interface change** — undocking a laptop, so the USB-dock Ethernet NIC goes away and Wi-Fi takes over — kills the in-flight streaming request and **ends the turn with no retry**. The session prints:

> `API Error: Connection lost mid-response. The response above may be incomplete.`

and stops. There is **no** `Retrying (n/10)`, and **no** `system`/`api_error` record is written to the session JSONL — unlike the transient failures in #87987, where the main loop logged `api_error` and recovered. Here the stream error is treated as a *terminal turn outcome*, not a retryable one.

This is not a "the network is broken" report. The interface swap is orderly and the new path is healthy within ~2 seconds; every other program on the machine rides through it. The client simply never tries again.

**Why this hurts disproportionately: it silently ends background sessions.** All six occurrences I can evidence were `sessionKind: "bg"`. For an interactive session you see the error and press enter. For a background job there is nobody to press enter: the runtime emits `turn_duration`, drains the queue, and the job sits idle. In one case queued task-notifications arrived 25 minutes later, were dequeued, and still produced no turn. Another background session was dead for **16 hours** until I typed "Status?" — work I believed was running had stopped at the moment I walked away from my desk, which is exactly when an undock happens.

### Evidence: exact same-second correlation with the NIC transition

Six occurrences in my local session transcripts. For the five inside the 32-day Windows event-log retention window, each one lands on the **same second** as a `Microsoft-Windows-NetworkProfile/Operational` **id=10001 (Network Disconnected)** event:

| Transcript timestamp (UTC) | NetworkProfile event | CC version | Recovered? |
|---|---|---|---|
| 2026-09-15 04:37:50 | 04:37:50 id=10001 Disconnected | 2.1.272 | No — session idle until reconnect 3h later |
| 2026-09-15 02:26:08 | 02:26:08 id=10001 → 02:26:10 id=10000 Connected | 2.1.272 | Yes, only because a queued task-notification drove a new turn |
| 2026-09-14 09:19:28 | 09:19:28 id=10001 Disconnected | 2.1.270 | No — dead 16h until I typed into it |
| 2026-09-14 08:03:10 | 08:03:10 id=10001 → 08:03:12 id=10000 Connected | 2.1.270 | No — idle despite the path being back in 2s |
| 2026-08-31 13:25:37 | 13:25:37 id=10001 Disconnected | 2.1.251 | Yes, only because a user message was already queued |
| 2026-08-17 07:38:25 | (outside log retention) | 2.1.233 | Yes, user typed 2 min later |

The pattern in the "recovered" rows is the point: recovery **never** came from a retry. It came from something else happening to enqueue a turn. With an empty queue, the session just stops.

The JSONL shape is identical every time — a real assistant message, then:

```
{"type":"assistant","message":{"model":"", ... "API Error: Connection lost mid-response. The response above may be incomplete."}}
{"type":"system","subtype":"turn_duration","durationMs":52967, ...}
```

No `api_error` record, no retry record, in between or after.

### Steps to Reproduce

1. Start a background session on a Windows laptop docked over USB-C Ethernet: `claude` with a long-running turn (a multi-minute tool sequence works well).
2. While the model is mid-stream, undock. Ethernet goes away, Wi-Fi associates within a couple of seconds.
3. Observe `API Error: Connection lost mid-response.` The turn ends. Nothing retries.
4. Leave the session alone with nothing queued. It stays idle indefinitely.

`Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NetworkProfile/Operational'} | Where-Object Id -in 10000,10001` gives the transition timestamps to line up against the session JSONL.

### Expected Behavior

A mid-stream socket loss should be retried like any other transient network error — re-resolve, open a **fresh** TCP connection on the current default route, and resume the turn. At minimum, a background session whose turn was terminated by a network error should not silently go idle; the harness should retry or surface a task notification so the job is recoverable without a human noticing it stopped.

### Environment

- Claude Code **2.1.272** (also 2.1.270, 2.1.251, 2.1.233 — long-standing, not a recent regression)
- Windows 11 Pro 10.0.26200 (x64)
- Node v24.20.0
- Model: claude-opus-5
- Wired NIC: Realtek USB 2.5GbE (dock). Wireless: Intel Wi-Fi 7 BE211. The Wi-Fi adapter re-enumerates across dock cycles (`Wi-Fi`, `Wi-Fi 2`, `Wi-Fi 5` all present, only one `Up`), so the interface index changes, not just the route.
- Tailscale is installed. It is **not** the trigger — the failing transitions are on the physical profile, and the many Tailscale-only up/down events in the same log produce no errors.
- No proxy, no VPN-based TLS inspection on this path.

### Related but distinct

- #89552 — macOS, Wi-Fi *drop*, sticky ECONNRESET that survives relaunch and needs a reboot. Mine is Windows, an orderly interface *swap*, the client is not poisoned (a new session works immediately), and the defect is the missing retry on the turn that was in flight.
- #87987 — subagent streams dying without retry. Same missing-retry theme, but that one's parent loop *did* log `api_error` and recover; here nothing is logged at all.