fix(mcp): restore the stale compatibility status for supported-but-behind clients

[minion1227]

What & why

classifyMcpClientVersion can return "stale", and LATEST_RECOMMENDED_MCP_VERSION
(0.6.0) exists precisely to mark a client that is at/above the minimum (0.5.0) but
behind the latest recommended. That arm was lost in the 0.4.0 release (#265), which
collapsed the classifier to a flat "current". That was only safe because #265 also set
MINIMUM_SUPPORTED === LATEST_RECOMMENDED, so the [minimum, latest) stale band was
empty and unreachable.

#745 later bumped LATEST_RECOMMENDED_MCP_VERSION to 0.6.0 and reopened the
[0.5.0, 0.6.0) band without restoring the stale arm. As a result, every
supported-but-behind client (e.g. any 0.5.x) is misclassified as "current".

Impact

This silently under-reports the staleEvents MCP-adoption counter (src/types.ts,
surfaced on the operator dashboard): auto-classified telemetry events could never land in
the stale bucket, so the dashboard reports zero stale adoption even when behind-version
clients are actively connecting. It's a metrics-correctness regression, not a
user-facing crash — which is why it went unnoticed.

The fix

Restore the original comparison against LATEST_RECOMMENDED_MCP_VERSION in
src/services/mcp-compatibility.ts. After the existing minimum checks pass, a version
in [minimum, latest) classifies as "stale"; >= latest stays "current":

const latestComparison = compareMcpSemver(version, LATEST_RECOMMENDED_MCP_VERSION)!;
return latestComparison < 0 ? "stale" : "current";

The ! is sound here: compareMcpSemver only returns null for an unparseable
version, and any such version already returned "unknown" at the minimumComparison
guard above, so by this line version is known-parseable.

Tests
Both arms covered in test/unit/mcp-compatibility.test.ts:
0.5.0 and 0.5.9 → "stale" (>= minimum, < latest)
0.6.0 and 0.7.1 → "current" (>= latest)
existing incompatible / unknown cases unchanged
Updated three pre-existing assertions that had encoded the buggy "current" output for a 0.5.0 client (the classifier unit test + two telemetry-event tests in mcp-compatibility.test.ts and mcp-server-telemetry.test.ts).

Risk
Behavioral change: 0.5.x clients now classify as stale instead of current. This is
the intended pre-#265 behavior and the reason LATEST_RECOMMENDED_MCP_VERSION exists.
No schema, migration, or generated-artifact changes.

---

A couple of things worth flagging before this goes up:

1. **No linked issue.** This is a regression-fix rationale PR. Per your gate rules, contributor PRs need a *valid linked issue* to auto-merge — confirm the repo accepts the rationale path for fixes, or this could auto-close one-shot.
2. The description references `#265`, `#745`, and `staleEvents`/`src/types.ts` — those came from the commit message. Want me to **verify those references are accurate** (that `staleEvents` exists in `src/types.ts` and the PR numbers are real) before you post, so nothing in the description is wrong?

Want me to tighten/shorten it, or run that verification?

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[JSONbored]

Closing this, and I won't be approving its CI run — here's why.

This account is permanently blocked from contributing to our repositories — for plagiarism. You filed two copies of another contributor's open work as your own:

• #1377 was an identical copy of kiannidev's #1376 (same source change, tests reworded to disguise the lift), filed ~90 minutes later on the same issue.
• #1378 was a byte-identical copy of kiannidev's #1373, filed ~2 hours later on the same issue.

That's two strikes, and lifting another contributor's diff is a hard line for us. Our Code of Conduct now states it explicitly: plagiarism and reward-farming result in a permanent block from contributing, across JSONbored/gittensory, JSONbored/metagraphed, and JSONbored/awesome-claude.

Because the account is blocked, there's no merit review to run here — I'm not going to approve the workflow just to evaluate a PR that closes regardless. Closed and labeled slop as enforcement of the ban. This decision is final.