docs: clarify extension negotiation for initialization-based versions - #3364

The Extensions Overview now shows only the per-request capability flow for 2026-07-28 and later. Readers using 2025-11-25 cannot readily find the initialize negotiation flow or understand why extensions is absent from that version's capability schemas.

This adds:

• A version signpost and 2025-11-25 initialize request/response examples to the overview, following SEP-2133.
• A short Extension Negotiation section in the 2025-11-25 lifecycle page linking to those examples.
• Clarification that extensions is optional, defined by SEP-2133, and absent from the older published schemas; SDK and extension compatibility still need to be checked.

Addresses the gap raised by Yousef and Cliff in the Skills over MCP WG discussion. This is a documentation clarification; no schema or protocol behavior changes.

SDK compatibility

Audit of official SDK default branches on 2026-09-15, pinned below. This checks carrying capabilities.extensions through the legacy handshake, not support for every extension or every published SDK release. Findings are from source inspection; the Python serialization loss was reproduced locally.

Python's serialize_server_result("initialize", version, ...) removes capabilities.extensions for all four supported legacy versions, including 2025-11-25, despite the public model exposing it.

Existing use before 2026-07-28

• Apps: Shipped on 2026-01-26. Its stable specification explicitly advertises io.modelcontextprotocol/ui through initialize, even showing protocol version 2024-11-05. This is direct precedent for the documentation clarification.
• Auth: Client Credentials and Enterprise-Managed Authorization were introduced with the November 2025 release. Their auth flows also use OAuth metadata before MCP initialization, so their existence alone does not establish support for the extensions capability field in every SDK.
• Tasks: Introduced experimentally in 2025-11-25, using capabilities.tasks. SEP-2663 subsequently moved and redesigned it as an extension. Earlier Tasks use is not evidence that today's io.modelcontextprotocol/tasks wire format works on legacy connections.

Suggested next steps

1. Merge the documentation clarification, retaining the SDK/extension compatibility caveat.
2. Decide whether to add an explicit optional extensions field to the legacy schemas as an additive erratum; until then, identify SEP-2133 as its definition.
3. Follow up with the Python SDK on the serialization loss and Java/Swift on native field support. Add client/server initialization round-trip tests, then verify released SDK versions before publishing a release-level support matrix.
4. Have extension maintainers state supported core protocol versions and migration behavior explicitly, especially for Tasks.

Validation: npm run prep completed successfully using a local shell adapter to run tsx scripts via node --import tsx because the environment blocks the CLI's IPC socket. Repository scripts are unchanged. Mintlify found no broken links. Both edited pages parse as MDX, both added JSON examples validate against the 2025-11-25 schema, added links/fragments resolve locally, and git diff --check passes. The initial CLI installation emitted dependency deprecation warnings.

AI assistance: Codex prepared and validated this change at Sambhav's request.