fix(docs): give AuthInfo interface a stable link target (#3012)

[karaaslanz]

Issue

Closes #3012.

TypeDoc's combined client/server API pages contain earlier authInfo? member headings before the public AuthInfo interface. The generated type links often point at #authinfo, which VitePress assigns to the member instead of the interface. The #authinfo-2 ordinal may shift as API members are added.

Fix

• On the two generated public API index pages only, inject a stable #authinfo-interface HTML anchor immediately before the actual AuthInfo interface heading.
• Rewrite only links whose displayed label is exactly AuthInfo and whose destination is the public client/server API index #authinfo (including local self-links). Preserve other member links and unrelated fragments.
• Add 3 self-contained Node tests for target selection and the non-target cases, and run them automatically from the existing docs:check CI script using tsx --test.

Verification & boundaries

• Independently reproduced the wrong link in generated TypeDoc Markdown from upstream main 9bc40e9, including a real authInfo? heading preceding the AuthInfo interface.
• Tested global useCustomAnchors and HTML anchor prefix on a Windows isolated package installation; those approaches cause duplicate heading IDs or leave cross-page links with the old fragment. Therefore this PR deliberately does not change global TypeDoc anchors.
• New helper tests: 3/3 PASS (Node's TypeScript-strip test runner). This narrow fix preserves existing member anchors rather than renumbering them.
• The complete VitePress build of this exact patch has not been run locally because the connected Windows session became unavailable. Upstream CI is the integration gate; please treat as draft until CI verifies the rendered site. An earlier unrelated full-site build blocker was the missing #intro region in a skill include.
• No generated API files or unrelated documentation pages committed.

CI verification (exact latest HEAD)

• Commit 6c6705e2b7eb7dd5f0a10db8001350b046d8cea8: GitHub Actions 4/4 workflows SUCCESS, including main build (docs:check with the 3 added regression tests), Node/e2e/runtime tests, examples, conformance and publish checks.
• The complete site build was validated by GitHub CI, not claimed as a local Windows run.
• Draft status remains because the connected GitHub integration returned FORBIDDEN for marking this pull request ready for review, and the authorized Windows gh CLI session is disconnected. No duplicate PR will be opened.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6c6705e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@3029

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@3029

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@3029

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@3029

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@3029

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@3029

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@3029

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@3029

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@3029

commit: 6c6705e