Bug: unexpected end of data when using custom API proxy with streaming responses

## Bug Description

When using a custom model API proxy (e.g. http://127.0.0.1:57321/v1), Codex++ Desktop intermittently throws unexpected end of data: line 1 column 217 (char 216) when opening certain project threads.

Root Cause Analysis

The error occurs because the local API proxy forwards streaming responses from the custom LLM backend to Codex++. When the streaming response is truncated mid-transfer (due to proxy timeout, network instability, or backend streaming interruption), the Codex++ Electron frontend receives an incomplete JSON payload and fails to parse it.

Key observations:

• Shared state files are intact: All local JSON files (.codex-global-state.json, session JSONL files, SQLite databases) have been verified to contain valid JSON/SQLite data.
• SQLite WAL files self-recreate: Deleting .sqlite-wal and .sqlite-shm files does not resolve the issue — they are regenerated on app launch, which is expected SQLite behavior.
• Multiple projects affected: The same error appears across different project workspaces (e.g. Invest, github-cli) because they all share the same API proxy endpoint and Codex++ global state.
• Proxy is alive: The local proxy at 127.0.0.1:57321 responds correctly to /v1/models requests, confirming the proxy itself is functional.

Environment

• OS: Windows 11
• Codex++ version: 0.140.0-alpha.2
• Model provider: Custom (model_provider = "custom")
• API base URL: http://127.0.0.1:57321/v1 (local proxy)
• Wire API: esponses
• Model: mimo-v2.5-pro

Steps to Reproduce

1. Configure Codex++ with a custom model API proxy endpoint
2. Have multiple project workspaces open with active conversations
3. Switch between projects or let conversations run for extended periods
4. Open a project thread → error unexpected end of data: line 1 column 217 (char 216) appears

Expected Behavior

Codex++ should gracefully handle truncated streaming responses from the API proxy, either by:

• Retrying the request automatically
• Showing a meaningful error message ("API response was interrupted, please retry")
• Not caching/loading corrupted partial responses into thread state

Suggestion

Add a try-catch around JSON parsing of API responses in the Electron frontend, with a retry mechanism for truncated streaming payloads. Also consider adding a "repair thread" button that reloads the conversation from the backend session JSONL files (which are always intact).