Upstream API error mid-task loses task state and silently redirects instead of resuming or surfacing it

### Observed
While building an editable figure, the agent returned `Upstream API error: Internal server error. Try again.` After the error, the turn restarted but changed direction -- instead of continuing the in-progress figure, it offered a fresh set of figure *options*, with no indication that the original figure had been abandoned. The user couldn't tell whether the figure had actually been generated.

### Expected
After a transient upstream error, Orbit should preserve in-flight task state and either auto-retry the same step or clearly state that the task did not complete and resume from where it left off -- not silently pivot to a different response.

### Why this is distinct
- Not #185 (TurnWatchdog handles *silent hangs* with no terminal event; here the error *did* surface).
- Not #261 (fabricated failure root cause + silent *local* fallback).

The gap is post-error continuity: a surfaced upstream 500 ends the turn, and the next turn starts fresh with no memory of the interrupted task, so the agent re-plans from scratch. Worth checking the error path in `app/src/renderer/chat/error-humanizer.ts` / `app.ts` for whether any in-progress task intent survives a mid-turn provider error. (In this session the figure write did eventually succeed, which made the "what state is this in?" confusion worse.) Sibling concern to #20 -- confirm task state to the user.

### Environment
Orbit (0.3.1 build), macOS arm64, provider anthropic / claude-opus-4-8.

Start by tracing the upstream-error path through app/src/renderer/chat/error-humanizer.ts and app.ts, checking whether in-progress task intent survives a surfaced provider error. Reproduce the mid-task error if possible and compare the resulting turn with the expected continuity. Done means the same step is retried or the user is clearly told the task did not complete and can resume from its prior state.

Written by the indexing model from the issue text.