feat(detect): resolve the Spring Framework version from the Boot BOM

[amondnet]

Problem

scripts/detect.ts resolves Spring Boot only. Since #21 the docs catalog also publishes framework (Spring Framework 6.1.x, 6.2.x, 7.0.x), but nothing maps a project onto a Framework version, so the skill has to ask the user for it:

Detection covers Spring Boot only, because Boot is what a build file declares. Spring Framework arrives as a transitive dependency of Boot and appears nowhere in build.gradle or pom.xml, so ask the user which Framework version they mean rather than guessing one from the Boot version.
— skills/spring-docs/SKILL.md

That is correct but weak: the project does pin a Framework version, just not anywhere a build-file parser can see it.

Why another build-file parser is the wrong fix

Framework is not declared. org.springframework:spring-core normally appears in no build.gradle or pom.xml at all — it arrives through spring-boot-dependencies, which pins it. Grepping build files for it would find nothing in a typical project, and would find a manual override in the atypical one, which is the only case the user could have answered accurately anyway.

Proposed direction

Resolve one declared Boot version into the component matrix through its BOM, rather than detecting components independently:

1. Detect the Boot version (already implemented, all three tiers).
2. Read spring-boot-dependencies:<version>'s managed versions — spring-framework.version and siblings.
3. Hand the resulting (project, version) pairs to docs.mjs.

Open questions for whoever picks this up:

• Where does the mapping live? Resolving the BOM at runtime means a network fetch and a POM parse per project. Publishing the mapping inside catalog.json moves that cost to the docs repository's build, at the price of a catalog schema change (schema version is currently 1, and SUPPORTED_CATALOG_VERSION gates on it).
• The offline path. --no-fetch currently serves a cached resolution. A BOM lookup needs its own cache or it breaks that guarantee.
• The Maven local-repo tier. scripts/lib/maven-cache.ts already reads ~/.m2; a BOM that is already there needs no network at all.

Not in scope

Security, Data and Cloud are not published by pleaseai/spring-docs yet. When they are, the same BOM resolution covers them — which is the argument for doing this once, generically, rather than per component.