[Bug]: startup hang

## QwenPaw Version

2.0.1b2 (Tauri desktop build; `/api/version` reported `2.0.1b2` through the day, `2.0.1` after latest update). Desktop shell + PyInstaller onedir backend (`qwenpaw-backend.exe`).

## Description

On every launch of the desktop app, background startup stalls for a consistent **~85–100 seconds in a completely silent internal wait**, on top of the PyInstaller boot time (65–199s). Total time-to-usable is 2.5–5 minutes. The desktop shell's health check gives up long before that, so the WebView shows **"failed to connect to backend"** even though the backend eventually comes up healthy and serves normally.

The same host, same config, on the previous pip-installed build (July 20 logs, `lib\site-packages` layout) completed background startup in **63.8s including connecting 11 MCP clients** — the new build's stall is additive and unrelated to MCP.

**During the ~90s stall the backend process has:**
- 0% CPU (0.09s CPU over a 5s sample)
- zero disk I/O
- zero outbound TCP connections (verified via `Get-NetTCPConnection` mid-stall)
- **zero child processes** (polled `Win32_Process` children every 3s across the whole window — no MCP server is ever spawned during the gap)

So it is a pure sleep/timeout on an internal event — not network, not DNS (resolvers answer in <1.2s), not MCP servers (all enabled servers handshake standalone in <10s), not model probing (all model capabilities cached, 0 probe events logged), not the local llama.cpp provider (healthy, serving concurrently).

**Security considerations:** none for the bug itself. (Side note: `workspaces//agent.json` stores MCP API keys in plaintext and they also leak into `workspaces//tool_results/*.txt`.)

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [x] Console (frontend web UI — error screen does not recover when backend becomes ready)

## Environment

- **QwenPaw version:** 2.0.1b2 / 2.0.1 (Tauri desktop)
- **OS:** Windows 11 Education 10.0.26200
- **Install method:** Desktop installer (Tauri shell + PyInstaller onedir backend, bundled Python/Node runtimes)
- **Python version:** bundled runtime (3.12)
- **Agents:** 4 (default, QwenPaw_QA_Agent_0.2, SafatMall, Khyber)
- **Providers:** ollama (127.0.0.1:11434, cloud models), custom OpenAI-compatible (llama.cpp/llama-swap on 127.0.0.1:8090/v1)

## Steps to Reproduce

1. Launch `qwenpaw-desktop.exe` (fresh start, no other instance).
2. Watch `~/.qwenpaw/qwenpaw.log`: `Server ready in 0.3s (agents loading in background)` appears quickly, first two workspaces start, ReMe memory managers log within ~1s.
3. Log goes **completely silent for ~85–100s** (nothing at any level; stderr also silent).
4. Startup resumes: `CommandRegistry initialized` → remaining workspaces start → `Background local model restore completed` → `Background startup completed in ~90s`.
5. Meanwhile the shell WebView has already shown "failed to connect to backend".

Reproduces on 7/7 launches today (durations: 84.6, 86.9, 90.0, 91.5, 95.9, 99.8, 103.2 s).

## Actual vs Expected

- **Actual:** background startup blocks ~90s in a silent internal wait between "ReMe memory manager started" (first workspace batch) and "CommandRegistry initialized"; UI shows "failed to connect to backend" and does not recover on its own once the backend is ready.
- **Expected:** startup completes in seconds (previous pip build: 63.8s total including 11 MCP client connects; the equivalent section ran in <1s there), and/or the shell keeps polling and recovers once the backend responds.

## Logs / Screenshots

Representative run (all runs identical in shape):

```
2026-07-24 11:41:24 | INFO | qwenpaw\app\_app.py:288 | Server ready in 0.308s (agents loading in background)
2026-07-24 11:41:24 | INFO | qwenpaw\app\workspace\workspace.py:475 | Starting workspace: default
2026-07-24 11:41:24 | INFO | qwenpaw\app\workspace\workspace.py:475 | Starting workspace: QwenPaw_QA_Agent_0.2
2026-07-24 11:41:25 | INFO | qwenpaw\agents\memory\reme_light_memory_manager.py:151 | ReMe memory manager started for agent 'QwenPaw_QA_Agent_0.2'
2026-07-24 11:41:25 | INFO | qwenpaw\agents\memory\reme_light_memory_manager.py:151 | ReMe memory manager started for agent 'default'
<-- 94 seconds of total silence; 0% CPU, no disk, no TCP, no child processes -->
2026-07-24 11:42:59 | INFO | qwenpaw\app\channels\command_registry.py:62 | CommandRegistry initialized
...
2026-07-24 11:43:0x | INFO | qwenpaw\app\workspace\workspace.py:475 | Starting workspace: SafatMall (instant)
2026-07-24 11:43:0x | INFO | qwenpaw\app\workspace\workspace.py:475 | Starting workspace: Khyber (instant)
2026-07-24 11:43:0x | INFO | qwenpaw\providers\provider_manager.py:1522 | Background local model restore completed
2026-07-24 11:43:0x | INFO | qwenpaw\app\_app.py:482 | Background startup completed in 91.497 seconds
```

Contrast with the previous pip build on the same machine/config (2026-07-20):

```
2026-07-20 11:40:11 | INFO | lib\site-packages\qwenpaw\app\_app.py:491 | Background startup completed in 63.841 seconds
2026-07-20 11:40:16 | INFO | lib\site-packages\qwenpaw\app\workspace\workspace.py:371 | Starting workspace: default
2026-07-20 11:40:16 | INFO | lib\site-packages\qwenpaw\app\mcp\stateful_client.py:467 | MCP client connected: brave-search
2026-07-20 11:40:17 | INFO | ... MCP client connected: context7 / exa / fetch / searxng / ... (all within 5s)
```

## Additional Notes

- Ruled out empirically: MCP server hangs (each enabled server — brave-search, context7, exa, fetch, searxng, sequential-thinking, perplexity, tavily, reme streamable-http — handshakes standalone in <10s; no MCP process is spawned during the gap at all), multimodal probe storms (all capabilities cached, 0 probes logged), custom provider connectivity (llama-swap on :8090 healthy and serving other clients during the gap), DNS (<1.2s), Windows Defender real-time (would show CPU/disk).
- The stall duration varies 84–103s, always once per startup, always at the same spot.
- **Workaround:** wait ~3 minutes after launch, then reopen the window from the tray — backend is healthy by then. The shell error screen does not auto-recover, which turns a slow start into an apparent total failure; a retry loop in the shell health check would mask the impact.
- The stall began after migrating from the pip install to the desktop (Tauri) build.