fix(cli): use MCP logging levels

[Bortlesboat]

Summary

Align the CLI's --log-level validation with the MCP logging specification. The accepted values now come from the SDK's LoggingLevelSchema, so the CLI no longer rejects valid RFC 5424 levels or forwards the non-spec trace and warn aliases.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Build/CI improvements

Changes Made

• Derive CLI logging levels from the MCP SDK schema instead of a parallel hardcoded list.
• Pass the schema-derived level to Client.setLoggingLevel without an unsafe cast.
• Pin schema parity and reject trace/warn at the CLI validation boundary.

Related Issues

Fixes #1734

Testing

• Tested in UI mode
• Tested in CLI mode
• Tested with STDIO transport
• Tested with SSE transport
• Tested with Streamable HTTP transport
• Added/updated automated tests
• Manual testing performed

Test Results and/or Instructions

• Full production build: npm run build
• CLI TypeScript build: npm run build-cli
• Focused regression: 3 passed (MCP spec logging levels and both non-spec aliases)
• Prettier check and git diff --check passed for both changed files

The broad CLI suite produced 60 passes and 28 Windows-only failures after successful HTTP responses because Node 24 aborted during transport teardown with UV_HANDLE_CLOSING. The affected focused tests do not use that teardown path and pass consistently.

Checklist

• Code follows the style guidelines (formatted and checked with Prettier)
• Self-review completed
• Code is commented where necessary
• Documentation updated (README, comments, etc.)

Breaking Changes

None.

Additional Context

Documentation is unchanged because the help text does not enumerate logging levels; its validation error now renders the SDK-derived list automatically. The change is limited to two CLI files.

[cliffhall]

Closing: v1 is deprecated.

Thank you for this contribution, and apologies for the long wait for a response.

v1 will receive security fixes only. We reviewed every open v1 PR for security impact before closing — see the backlog triage in #1819 — and a small number were retained for a final 1.0.5 patch release. This one is a functionality, compatibility, or cleanup change rather than a vulnerability fix, so it is being closed unmerged. This is not a judgment on the quality of the work — it's a consequence of the branch it targets being frozen.

If the underlying problem still exists in v2, we'd genuinely like to know. Please open an issue describing it against v2. Note that we accept external contributions as issues rather than pull requests — maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTORS.md.

Thanks again for taking the time to contribute to the Inspector.