chore(upgrade): sync dependency metadata with AppCAT rules

[frankliu20]

Align EOL/deprecated thresholds with AppCAT azure rulesets:

• Spring Boot: supportedVersion >=3.5.x, suggest 4.0
• Spring Framework: supportedVersion >=6.2.x, suggest 7.0
• Spring Security: supportedVersion >=6.5.x, suggest 6.5
• Add Spring Cloud (>=2025.x)
• Jakarta EE: suggest version 11
• Update eolDate to OSS support end dates

[wenytang-ms]

Spring Cloud entry: version-scheme mismatch (likely false positives)

The new org.springframework.cloud:* rule is expressed in release-train calendar versions (supportedVersion: ">=2025.x", eolDate keyed 2025.x…2021.x, suggestedVersion: "2025.0"), but the assessment engine compares these against the resolved artifact version of each jar via semver.coerce(...) + semver.satisfies(...).

Spring Cloud is the one project where the two differ: the release train is calendar-versioned, but the individual org.springframework.cloud:* jars are semantically versioned. Maven Central confirms spring-cloud-commons latest release = 5.0.1 (versions go 1.x → 2.x → … → 5.x, never 2025.x).

Consequences (verified with the repo's semver):

• 5.0.x (the current 2025.0.x train) → satisfies(">=2025.x") = false → flagged as EOL. False positive on the newest release.
• 4.1.5 (2023.0.x train) → flagged, but findEolDate("4.1.5") matches no 20xx.x range → the message shows no EOL date and reads like "Spring Cloud 4.1.5 … upgrade to 2025.0".

Only literal calendar versions — which never appear as resolved jar versions — would pass.

Suggestion: either express the rule in the modules' semantic versions (e.g. >=5.x, with eolDate keyed 4.1.x, 4.0.x, …), or drop the Spring Cloud entry until a train→module-version mapping exists.

Separately, this hunk is a good concrete example of a broader question worth aligning on: who should own the authoritative framework-EOL catalog (App Modernization) vs. what this extension detects locally (JRE + nudge). Happy to discuss offline.