docs: apply linkification to chapters added on main

Same policy as the previous commit, applied to the newly added MCP Apps,
Extensions, and Dependencies chapters and the new migration/elicitation
sections: chapter cross-references in the Dependencies and Elicitation
pages become bold-wrapped links, and SEP-2133 mentions link to the
proposal PR (prose first-mention and the migration section heading).

Author: maxisbey

docs/advanced/extensions.md

@@ -4,7 +4,7 @@ An **extension** is an opt-in bundle of MCP behaviour behind one identifier.
 
 It can contribute tools, resources, and new request methods, and it can wrap `tools/call`.
 The server advertises it under `capabilities.extensions`, the client opts in the same way,
-and nothing changes for anyone who didn't ask for it. That is the contract (SEP-2133), and
+and nothing changes for anyone who didn't ask for it. That is the contract ([SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133)), and
 it has one golden rule: **extensions are off by default**.
 
 ## Using an extension

docs/migration.md

@@ -407,7 +407,7 @@ On `ClientSession`, `call_tool` / `get_prompt` / `read_resource` still return th
 
 For protocol 2026-07-28 over Streamable HTTP, a tool's input-schema property may carry an `x-mcp-header` annotation. When a tool the client has listed is called, each annotated argument is mirrored into an `Mcp-Param-<name>` request header (string verbatim, integer as decimal, boolean as `true`/`false`, base64-sentinel-wrapped when not header-safe; `null`/absent arguments are omitted). The argument is also left in the request body. `list_tools` caches a tool's annotations, so list a tool before calling it to enable mirroring; a tool the client never listed emits no `Mcp-Param-*` headers. Other transports ignore the annotation.
 
-### Server extensions API (SEP-2133)
+### Server extensions API ([SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133))
 
 `MCPServer` now accepts opt-in extensions that bundle MCP behaviour behind a
 reverse-DNS identifier and advertise it under `ServerCapabilities.extensions`

docs/tutorial/dependencies.md

@@ -35,7 +35,7 @@ Here is the input schema `tools/list` reports for `reserve_book`:
 }
 ```
 
-One property. Like the `Context` in **The Context**, a resolved parameter is a contract between you and the SDK: `stock` is not in the schema, the model is never told about it, and a client that sends a `stock` value anyway is ignored. The resolver's value is the only one your tool can receive.
+One property. Like the `Context` in **[The Context](context.md)**, a resolved parameter is a contract between you and the SDK: `stock` is not in the schema, the model is never told about it, and a client that sends a `stock` value anyway is ignored. The resolver's value is the only one your tool can receive.
 
 That last part is the point. A parameter the model cannot supply is a parameter the model cannot get wrong.
 
@@ -84,16 +84,16 @@ A resolver's parameters resolve exactly like a tool's: another `Resolve(...)`, t
 !!! warning
     On HTTP transports the `Context` includes `ctx.headers`. Headers are **client-supplied input**,
     like any tool argument: fine for a locale or a feature flag, never an identity. Who the caller
-    is comes from your authorization layer (**Authorization**), not from a header anyone can set.
+    is comes from your authorization layer (**[Authorization](../advanced/authorization.md)**), not from a header anyone can set.
 
 !!! tip
     *Once per call* means exactly that: the next `tools/call` runs `check_stock` again. A resource
-    that should outlive a request - a database pool, an HTTP client - belongs in **Lifespan**, and
+    that should outlive a request - a database pool, an HTTP client - belongs in **[Lifespan](lifespan.md)**, and
     a resolver can reach it through `ctx.request_context.lifespan_context`.
 
 ## Ask when you must
 
-A resolver doesn't have to know the answer. It can return `Elicit(message, Model)` and the SDK asks the user - the **Elicitation** machinery, run for you:
+A resolver doesn't have to know the answer. It can return `Elicit(message, Model)` and the SDK asks the user - the **[Elicitation](elicitation.md)** machinery, run for you:
 
 ```python title="server.py" hl_lines="26-32 39"
 --8<-- "docs_src/dependencies/tutorial003.py"
@@ -114,7 +114,7 @@ And if the user won't answer at all - declines the question, or cancels it?
     Error executing tool order_book: Resolver for parameter 'backorder' could not resolve: elicitation was decline
     ```
 
-That's the right default for a precondition: no answer, no order. When declining is an outcome your tool wants to handle - skip the backorder but still suggest another title - annotate `ElicitationResult[Backorder]` instead and the tool receives the full accept/decline/cancel outcome to branch on. **Elicitation** shows that form, and everything else about asking: the schema rules, the three answers, the client's side of the conversation.
+That's the right default for a precondition: no answer, no order. When declining is an outcome your tool wants to handle - skip the backorder but still suggest another title - annotate `ElicitationResult[Backorder]` instead and the tool receives the full accept/decline/cancel outcome to branch on. **[Elicitation](elicitation.md)** shows that form, and everything else about asking: the schema rules, the three answers, the client's side of the conversation.
 
 ## Recap
 
@@ -124,4 +124,4 @@ That's the right default for a precondition: no answer, no order. When declining
 * Bad graphs fail at registration with `InvalidSignature`, not mid-call.
 * Return `Elicit(message, Model)` to ask the user, only when you have to. Unwrapped annotations abort on decline; `ElicitationResult[T]` lets the tool branch.
 
-Next: what happens when your tool fails, and how to choose who finds out, in **Handling errors**.
+Next: what happens when your tool fails, and how to choose who finds out, in **[Handling errors](handling-errors.md)**.

docs/tutorial/elicitation.md

@@ -95,7 +95,7 @@ A parameter annotated `Annotated[T, Resolve(fn)]` is filled by running `fn` befo
 
 Annotate the unwrapped model (`Annotated[Confirm, Resolve(confirm_delete)]`) instead when the tool doesn't need to branch: it receives the model on accept and the call aborts with an error on decline or cancel.
 
-Asking is only one thing a resolver can do. The general mechanism - dependencies that compute without asking, dependencies of dependencies, what the model can and cannot supply - is the **Dependencies** chapter.
+Asking is only one thing a resolver can do. The general mechanism - dependencies that compute without asking, dependencies of dependencies, what the model can and cannot supply - is the **[Dependencies](dependencies.md)** chapter.
 
 ## Send the user to a URL