Fix MCP server status drift after auth, restart, and reload flows

[samhu1]

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.