Fix broken section links

When generating heading IDs, Mintlify converts all non-word characters
to dashes.  For example, "2.3.2" becomes "2-3-2".

This also fixes an incorrect section number in a link that was missed by
463a5a2.

Author: jonathanhefner

docs/specification/2025-03-26/basic/authorization.mdx

@@ -158,7 +158,7 @@ domain hosting the MCP server, regardless of any path components in the MCP serv
 
 For servers that do not implement OAuth 2.0 Authorization Server Metadata, clients
 **MUST** use the following default endpoint paths relative to the authorization base URL
-(as defined in [Section 2.3.2](#232-authorization-base-url)):
+(as defined in [Section 2.3.2](#2-3-2-authorization-base-url)):
 
 | Endpoint               | Default Path | Description                          |
 | ---------------------- | ------------ | ------------------------------------ |

docs/specification/draft/basic/authorization.mdx

@@ -306,7 +306,7 @@ An attacker can gain unauthorized access or otherwise compromise a MCP server if
 This vulnerability has two critical dimensions:
 
 1. **Audience validation failures.** When an MCP server doesn't verify that tokens were specifically intended for it (for example, via the audience claim, as mentioned in [RFC9068](https://www.rfc-editor.org/rfc/rfc9068.html)), it may accept tokens originally issued for other services. This breaks a fundamental OAuth security boundary, allowing attackers to reuse legitimate tokens across different services than intended.
-2. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the "confused deputy" problem, outlined in [Section 3.4](#34-confused-deputy-problem), where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API. See [Security Best Practices 2.2](/specification/draft/basic/security_best_practices) for additional details.
+2. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the "confused deputy" problem, outlined in [Section 3.5](#3-5-confused-deputy-problem), where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API. See [Security Best Practices 2.2](/specification/draft/basic/security_best_practices) for additional details.
 
 MCP servers **MUST** validate access tokens before processing the request, ensuring the access token is issued specifically for the MCP server, and take all necessary steps to ensure no data is returned to unauthorized parties.