Desktop: unparseable managed-agents.json wedges boot and presents as "Community connection failed" — no quarantine, no surfaced error

### Summary

When `managed-agents.json` contains a single record that fails serde parsing, the desktop app stalls during boot and the UI presents it as **"Community connection failed"** — indistinguishable from a relay outage, with no error surfaced to the user and no recovery path short of hand-editing app data.

This happened today on a real install: an external repair rewrote the store with one required field (`agent_args`, the only `Vec` field on `ManagedAgentRecord` without a `#[serde(default)]`) missing from five records. The app launched, showed the community-connection failure, spawned nothing, wrote nothing — for ~15 minutes until the store was fixed. The relay was healthy the entire time.

### Why this is sharp

- The strict-read design is intentional ("a malformed file is a fail-loud error — never an empty read that would orphan every retained head" in `event_sync.rs`'s `read_agents_strict`) — that's the right call for *sync*, but the same parse failure propagating to community init turns one bad record into a full-app outage.
- The failure is silent: `eprintln!` diagnostics are invisible in a GUI launch (Finder/`open`), and nothing appears in the UI or unified log pointing at the store.
- The store format is effectively load-bearing for boot, yet it is also the file most likely to be corrupted by a crash, disk-full, or (as here) an external tool — even though writes go through `atomic_write_json_restricted`, any *content*-level breakage has the same effect.

### Reproduction

1. Quit the app.
2. Remove `"agent_args": []` from any record in `~/Library/Application Support//agents/managed-agents.json` (or otherwise break one record's shape).
3. Relaunch. Boot wedges; UI shows "Community connection failed" despite a healthy relay; agents do not restore; the store is never rewritten.

(Verified before/after: adding the field back restored normal boot immediately.)

### Suggested directions

- **Quarantine + continue:** on store parse failure at boot, move the bad file aside (the app already rotates `.bak-` copies), boot with an empty store, and surface a persistent, specific error ("agent store was corrupt; moved to X; N agents not loaded"). This mirrors the fail-safe the fold migration already uses for `personas.json`.
- **Surface the parse error:** route store-load failures to the UI error surface, not just `eprintln!`, so the failure mode isn't indistinguishable from a network problem.
- Optionally, a lint/repair pass: if specific records fail to parse, drop-and-report just those records (with a backup) instead of failing the whole store — with the retained `.bak` copies, recovery data still exists.

### Related

- Similar shape to #5155 (store corruption symptoms), but that one concerns duplicate entries/model dropdowns; this is the boot-wedge failure mode itself.
- Cross-ref: #7611 — the incident that surfaced this.