fix(store): resolve partial semver versions like "1.20" in findBestVersion

[lloydpick]

Summary

Fixes #480 — partial semver versions like "1.20" are permanently unmatchable via find_version/search_docs, even though findBestVersion()'s own target-matching logic already treats this format as valid (its versionRegex matches 1.2/1, and the search_docs MCP tool's own description documents 5.x/5.2.x X-range examples as supported input).

Related to but broader than #475, which reports genuinely non-semver labels ("latest") specifically — this covers real, common version formats a lot of projects actually use (major.minor with no patch — e.g. Cilium versions its own docs as 1.20, not 1.20.0).

Root cause

Two independent strictness bugs, both needed fixing:

1. listVersions() filtered with semver.valid(), which requires a full X.Y.Z string. semver.valid("1.20") → null, so a version stored literally as "1.20" was silently dropped and never even reached findBestVersion()'s matching logic.
2. semver.maxSatisfying() also requires every candidate to itself be a fully valid X.Y.Z string — semver.maxSatisfying(["1.20"], "1.20") → null. So even after fixing Allow exceeding the maximum chunk size if a chunk cannot be split further #1, matching would still fail without coercing candidates first.

Repro

Indexed cilium under null (unversioned), "1.20", and "stable". Before the fix:

find_version(cilium, "1.20") -> "No matching version found for cilium@1.20, but unversioned docs exist."
find_version(cilium)         -> "No matching version found for cilium, but unversioned docs exist."

"1.20" was completely unreachable via its own version string despite having been successfully indexed. search_docs masked this by silently falling back to the unversioned bucket regardless of the version param passed (SearchTool.ts, exactMatch hardcoded false for the MCP interface) — which is also why this can present as an outright "Library not found in store" failure (matching #475's report) whenever no unversioned copy happens to exist to fall back to.

Fix

1. listVersions(): filter with semver.coerce(v) !== null instead of semver.valid(v).
2. findBestVersion(): build a coerced -> original map, match on the coerced candidates, then resolve back to the original stored string (so downstream lookups like checkDocumentExists() still use what's actually in the store).

Test plan

• listVersions(): partial versions ("1.20", "5") are now included and sort correctly alongside full versions; non-versions ("stable") stay excluded
• findBestVersion(): resolves an explicit "1.20" request to the original stored string; picks the highest partial version when no target is given; a non-semver label like "stable" still correctly falls through to unversioned (unchanged, correct behavior)
• All pre-existing tests in both files continue to pass unchanged
• npm run lint, npm run typecheck, npx vitest run src/store/DocumentManagementService.test.ts all pass
• Verified live against a real cilium@1.20 scrape with a local build: find_version now returns "Best match: 1.20" instead of failing

[arabold]

Good changes. Thanks for the report and fix. Two comments below as this breaks prerelease versions and can cause conflicts. Probably rare, but should be easy enough to include.

[arabold]

Could we avoid keeping just one original label for each normalized version? If both a partial version and its full form are stored, one replaces the other here, and looking up the partial form can return a different version label. Please add coverage for both stored forms.

Something like this:

type VersionCandidate = {
  stored: string;
  normalized: string;
  strict: boolean;
};

[arabold]

This destroys prerelease labels (2.0.0-beta becomes 2.0.0), so a request for the prerelease can fail or it can win over the real stable release. A small regression test covering both would help.