Adopt the SDK's Skills client (SEP-2640) and replace the Inspector's own Skills protocol code #2804

Problem

The Inspector supports the Skills extension (SEP-2640) through its own implementation, built in #2234 and #2248 before the SDK had one. That covers skills/list, skills/get, resources/directory/read, and size/digest/frontmatter verification, in about 2.3k lines of core/:

• core/mcp/skills.ts
• core/mcp/skillsSchemas.ts
• core/mcp/skillsVerification.ts
• core/mcp/skillFile.ts

MCP TypeScript SDK 2.4.0 (adopted in #2784 / #2799) now ships the client side of the same extension:

• @modelcontextprotocol/client/ext/skills: SkillsClient with list() (skipInvalid: true returns invalid entries separately), get(), read(skill, path?) (verifies size, digest and SKILL.md frontmatter, throws SkillVerificationError on a mismatch, and re-fetches a stale cached copy once with cacheMode: 'refresh'), and readDirectory().
• @modelcontextprotocol/core/ext/skills: the schemas, types and constants, including SKILL_LIMITS. Its result schemas follow the stable spec, so ttlMs and cacheScope are required on 2026-07-28 (the requirement Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404 and Modern resources/directory/read results must carry ttlMs and cacheScope (ext-skills stable spec) #2740 had to add to ours by hand).

It works on 2025-11-25 and 2026-07-28. The SDK's announcement marks only the server-side SkillsExtension.attach as @experimental; the client API is stable.

So, as with Tasks before #2565, the Inspector is carrying a second copy of protocol logic the SDK now owns, and every spec change has to be tracked twice.

What to do

Replace the Inspector's Skills protocol code with the SDK's, following the shape #2565 set up for Tasks:

• Take schemas, types and constants from @modelcontextprotocol/core/ext/skills, and drive list/get/read/readDirectory through SkillsClient.
• Delete the Inspector's copies those replace.
• Keep what the SDK does not cover in core/extension/skills/, importing nothing from InspectorClient. For example:
  • the conformance report behind --verify and the TUI/web verify views. An Inspector needs to report each check's outcome, including a skill whose resources are dynamic and cannot be hashed (--verify reports outcome "verified" and exits 0 for a skill whose resources are "dynamic", with nothing hashed #2405), not just throw on the first mismatch.
  • showing invalid entries rather than dropping them (the skipInvalid / invalid split may be enough)
  • the client-capability declaration (Inspector never declares the skills extension in its client capabilities #2373)
• Confirm the ext/skills subpath imports stay external in the built output. The bundler external lists (clients/{mcpdo,tui}/tsup.config.ts, clients/web/tsup.runner.config.ts) already name @modelcontextprotocol/client and core, which should cover their subpaths; npm run verify:bundle-externals checks the built output.

First step: compare SkillsClient's verification against ours before deleting anything. Where the SDK is stricter, looser, or reports less than the Inspector needs to show, that part stays ours in core/extension/skills/. Write down which parts were kept and why.

No user-facing behavior change: the Skills screens in all three clients stay as they are, and both protocol eras must keep working end to end.