Refresh MCP runtimes across thread startup (#35204)

## Why

MCP configuration can change while a thread is still starting, before it appears in the thread manager's loaded-thread list. In that window, invalidation could miss the new thread and leave it with a stale MCP runtime.

## What changed

- Centralize MCP runtime invalidation in `ThreadManager` so it refreshes loaded threads and marks in-progress thread startups for refresh after publication.
- Use the centralized invalidation path for account and plugin changes.
- Invalidate MCP runtimes after successful server and plugin OAuth logins.

## Testing

- Add a regression test that pauses thread startup, invalidates MCP runtimes, and verifies that the newly published thread refreshes its MCP projection.

GitOrigin-RevId: 8944f5a21816a1405e038a0d4c08b66362ea9368

codex-rs/app-server/src/effective_plugin_change.rs

@@ -33,10 +33,7 @@ pub(crate) fn effective_plugins_changed_callback(
 
         let refresh_thread_manager = Arc::clone(&thread_manager);
         tokio::spawn(async move {
-            if refresh_thread_manager.list_thread_ids().await.is_empty() {
-                return;
-            }
-            crate::mcp_refresh::invalidate_loaded_threads(&refresh_thread_manager).await;
+            refresh_thread_manager.invalidate_mcp_runtimes().await;
         });
 
         if change.materialized_remote_plugins.is_empty() {