fix(mcp): reset AsyncExitStack after cleanup for reconnect (#618)

[Abdeltoto]

Problem

\AsyncExitStack\ cannot be reused after \�close(). After \cleanup(), a second \connect()\ (e.g. \MCPServerManager.reconnect()) would call \enter_async_context\ on a closed stack, which is invalid and can contribute to resource leaks / shutdown warnings (see #618).

Change

• In _MCPServerWithClientSession.cleanup(), after clearing session state, assign a new \AsyncExitStack()\ and clear \server_initialize_result.
• Add \ est_connect_after_cleanup_uses_fresh_exit_stack\ (connect → cleanup → connect → cleanup).

Testing

• 
  uff check\ on touched files: OK.
• Full \ ests/mcp/\ requires Unix \ ee\ on \PATH\ (see \ ests/mcp/helpers.py); on Windows use WSL or CI.
  
  Fixes Resource tracker warning (leaked semaphores) with MCPServerStdio #618

Made with Cursor

[seratch]

I think we should be a bit more careful about resetting self.exit_stack in the finally block.

MCPServerManager can run cleanup() under a timeout, so self.exit_stack.aclose() may be cancelled while it is still unwinding callbacks. In that case cleanup() re-raises CancelledError, but this change still replaces the original stack with a fresh AsyncExitStack().

If aclose() was interrupted partway through, that drops the remaining callbacks from the original stack, and a later cleanup retry can no longer finish closing the transport/process. That seems like it could turn a teardown timeout into a resource leak.

Could we keep the existing stack on cancellation, and only create a fresh AsyncExitStack() after aclose() completes successfully?

[github-actions]

This PR is stale because it has been open for 10 days with no activity.