Fix MCP server status drift after auth, restart, and reload flows #38
Description
Problem
The app exposes MCP server status in both draft and live-session flows, but the status model is assembled from multiple sources: direct probing, runtime-reported status, and OAP reload/restart behavior. That makes it easy for a server to appear healthy when it is not, or to remain in an outdated needs-auth / pending / connected state after the session has been reloaded.
Why this matters
Incorrect MCP status is a product bug with real workflow impact. Users may assume a tool is ready when it is not, skip a required auth step, or restart a session unnecessarily. Contributors working on MCP-related features also need a reliable status model before adding new server management UX.
Areas to inspect
- Draft-mode MCP probing
- Runtime-reported MCP statuses for active sessions
- OAP reload-session flows
- OAuth completion and restart behavior
- Newly added / removed server reconciliation
Acceptance Criteria
- MCP status should converge to a single current truth after auth, session restart, or server removal.
- A server that needs auth should not remain marked connected after a failed reload.
- Draft and active-session status indicators should use consistent terminology and state transitions.
- Reloading a session with updated servers should refresh status without requiring manual UI refresh.
- Add targeted tests or at minimum deterministic repro notes covering add, auth, reload, and remove flows.