fix(tier-check): strip package-name prefixes from monorepo release tags

[hwkiem]

Fixes #425.

checkStableRelease stripped only a leading v, so per-package tags like rmcp-v3.1.3 parsed to NaN and scored stable_release: fail. The version is now matched at the end of the tag, so any package-name prefix is ignored.

Motivation and Context

stable_release feeds both the Tier 1 blocker list and the Tier 2 gate, so a monorepo SDK is scored below what its releases support. Running against rust-sdk with --skip-conformance, main reports fail with version: "rmcp-v3.1.3" and lists stable_release in tier1_blockers; since tier2Met also requires is_stable, the implied tier is 3. With this change the check reports pass with version: "3.1.3" and the implied tier is 2. Both runs skip conformance, so those legs block Tier 1 either way and stable_release is the only difference.

How Has This Been Tested?

Ran the issue's repro against the live repo on both main and this branch:

node dist/index.js tier-check --repo modelcontextprotocol/rust-sdk --skip-conformance --output json

// main
"stable_release": { "status": "fail", "version": "rmcp-v3.1.3", "is_stable": false }
// this branch
"stable_release": { "status": "pass", "version": "3.1.3", "is_stable": true }

Since this is shared infrastructure, I ran the same comparison across all eight official SDKs. rust-sdk is the only row that changes:

                    main                          this branch
go-sdk          pass  1.7.0        tier 2     pass  1.7.0        tier 2
csharp-sdk      pass  2.2.0        tier 3     pass  2.2.0        tier 3
typescript-sdk  pass  1.30.0       tier 2     pass  1.30.0       tier 2
python-sdk      pass  2.0.0        tier 2     pass  2.0.0        tier 2
java-sdk        pass  2.0.0        tier 2     pass  2.0.0        tier 2
kotlin-sdk      fail  0.15.0       tier 3     fail  0.15.0       tier 3
ruby-sdk        pass  1.2.0        tier 2     pass  1.2.0        tier 2
rust-sdk        fail  rmcp-v3.1.3  tier 3     pass  3.1.3        tier 2

kotlin-sdk still failing at 0.15.0 is the useful half: the change ignores a package-name prefix without making the check permissive about pre-1.0 versions.

New release.test.ts adds 10 cases driving checkStableRelease through a stubbed Octokit. Five cover the monorepo tags and fail against main; the other five are regression guards (bare tags, v prefixes, the GitHub prerelease flag, unparseable tags, empty release list) and pass either way. Full suite green at 534 tests, with typecheck and lint clean.

Breaking Changes

None. The version field now reports the parsed version rather than the raw tag, so a monorepo SDK surfaces "3.1.3" where it previously surfaced "rmcp-v3.1.3". That matches what already happened for v-prefixed tags.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

releases.find((r) => !r.draft) still takes the most recent published release regardless of which package it belongs to, so on a workspace the check can score whichever crate released last. The issue cites both rmcp-v3.0.1 and rmcp-macros-v3.0.1 as tags that should be recognized, so that behavior is left alone here. Happy to follow up if per-package selection is wanted.