Refresh session components on re-registration in ClientSessionGroup

[abhay-2108]

Fixes #3713

Problem

When re-registering an already-connected caller-owned session with a changed catalog via connect_with_session(), the internal _sessions[session] reverse index was overwritten while previously registered names in _tools and _tool_to_session were left behind. Subsequent calls to disconnect_from_server(session) then left orphaned tools in the group.

Changes

1. Eviction on re-registration: In _aggregate_components(), when re-registering an existing session, its previously registered components are evicted before aggregating the new catalog.
2. Duplicate check refinement: The duplicate collision checks now exclude the session's own existing registrations so re-registering does not falsely trigger collision against itself.
3. Empty-catalog guard: Guarded del self._session_exit_stacks[session] with if session in self._session_exit_stacks: so caller-owned sessions registering or refreshing to an empty catalog do not encounter a KeyError.
4. Documentation: Updated docs/client/session-groups.md under Adding and removing servers and Recap describing connect_with_session() refresh and collision behavior.
5. Tests: Added tests in tests/client/test_session_group.py asserting full invariants across tools, prompts, resources, _tool_to_session, _sessions[session], routing, and error behavior.

Verification

• pytest tests/client/test_session_group.py: 18 passed in 0.40s
• coverage: 100.00% statement and branch coverage on src/mcp/client/session_group.py
• ruff check . & ruff format --check .: Clean
• pyright: 0 errors, 0 warnings

---

Assisted by AI (Antigravity), reviewed and verified by human contributor.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3713.

If a maintainer assigns you to #3713, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.