Clear Working state when a model call fails before a response

[mohitranka]

Summary

• Found in the same usability audit that surfaced Fail turns whose model text looks like an unparsed tool call #119: after a provider/HTTP error (or any error occurring before apply_model_response ever produces a ModelResponse), the session's TaskLifecycle stayed stuck at Working forever. The header showed a permanently-animating "Working" spinner, and every later message silently joined the queue and never dispatched — confirmed to survive switching to a completely different, healthy provider. Only killing and restarting the process cleared it.
• Root cause: drain_pending_prompt in crates/forge-tui/src/app/turn.rs funnels every non-success outcome (provider/HTTP error, task-join error, or apply_model_response itself returning Err) into a shared outcome_err variable. The success path (apply_model_response returning Ok) has full lifecycle-transition logic; this error path only cleared the TUI-local busy flag and called report_error for the on-screen banner — nothing ever moved AgentSession::active_task.lifecycle out of Working. Since the message queue's dispatch gate (classify_input) and start_new_task both refuse to act while lifecycle == Working, and provider switches never touch that field either, the session was permanently soft-locked.
• Fix: added AgentSession::mark_model_call_failed (crates/forge-core/src/lib.rs), mirroring the existing mark_cancelled's shape — a lifecycle-only transition (Working|Waiting -> Failed, TransitionReason::TurnFailure) with no synthetic assistant message, since the TUI's report_error already shows the failure to the operator and duplicating it into the transcript would just be noise. Wired into the non-cancel branch of outcome_err handling in turn.rs.

Test plan

• cargo test --package forge-tui — 671/671, including a new regression test edge_provider_error_unsticks_session_for_the_next_message (fails a turn, then sends a second message and asserts it dispatches immediately rather than queuing) and a new lifecycle assertion added to the pre-existing edge_network_stream_interruption_preserves_partial_response (which exercises the same code path but never checked the session lifecycle before).
• cargo fmt --all -- --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --all-targets --locked — all clean.
• Re-ran the exact live repro against the real release binary: triggered the still-open cache_control P0 on OpenAI Codex (header went ✗ Failed · Model call failed instead of stuck Working), then switched to Ollama and sent two more messages through two more real errors (gemma3:4b does not support tools, then the dangling-tool-call catch from Fail turns whose model text looks like an unparsed tool call #119) — every message dispatched immediately, none silently queued, no stuck state at any point.