#1981: fix ide update failing on windows arm64

[cap-juan]

This PR fixes #1981

Implemented changes:

• Added a fallback from windows-arm64 to windows-x64 when no native Windows ARM64 snapshot artifact is available.
• Added snapshot metadata inspection to verify which platform classifiers are actually published.
• Added short-term caching for Maven metadata to avoid downloading and parsing the same maven-metadata.xml multiple times.
• Kept the fallback limited to Windows ARM64 so that Linux and macOS artifact resolution remain unchanged.
• Added tests covering the ARM64 fallback, existing ARM64 artifacts, unsupported classifiers, and snapshot-version resolution.

Testing instructions

1. Run the focused Maven repository tests:
   mvn -pl cli -Dtest=MvnRepositoryTest test

2. Run the complete test suite:
   mvn clean test

3. Build and install the modified IDEasy version locally:
   ./build-local-dev.sh

4. Open a new PowerShell session and simulate Windows ARM64:
   $env:IDE_OPTIONS = "-Dos.arch=arm64"

5. Verify the simulated architecture:
   ide status

6. Run the previously failing snapshot upgrade:
   ide upgrade --mode=snapshot

7. Verify that IDEasy falls back to the windows-x64 artifact instead of failing with a 404 for windows-arm64.

8. Remove the architecture override after testing:
   Remove-Item Env:IDE_OPTIONS -ErrorAction SilentlyContinue

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

Checklist for tool commandlets

Have you added a new «tool» as commandlet? There are the following additional checks:

• The tool can be installed automatically (during setup via settings) or via the commandlet call
• The tool is isolated in its IDEasy project, see Sandbox Principle
• The new tool is added to the table of tools in LICENSE.asciidoc
• The new commandlet is a command-wrapper for «tool»
• Proper help texts for all supported languages are added here
• The new commandlet installs potential dependencies automatically
• The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet
• The new commandlet is tested on all platforms it is available for or tested on all platforms that are in scope of the linked issue

[coveralls]

Coverage Report for CI Build 32706969753

Coverage increased (+0.1%) to 73.574%

Details

• Coverage increased (+0.1%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 27 coverage regressions across 2 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

27 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/tool/mvn/MvnRepository.java	24	78.82%
com/devonfw/tools/ide/tool/mvn/MvnArtifact.java	3	88.8%

---

Coverage Stats

Relevant Lines:	18089
Covered Lines:	13917
Line Coverage:	76.94%
Relevant Branches:	8037
Covered Branches:	5305
Branch Coverage:	66.01%
Branches in Coverage %:	Yes
Coverage Strength:	3.28 hits per line

---

💛 - Coveralls

[maybeec]

Thanks for picking this one up 👍 The diagnosis matches the analysis in #1981 exactly — read the snapshot maven-metadata.xml, check which classifiers actually exist, and fall back — and reusing CachedValue for the parsed Document is the right building block. Commits follow #«issue-id»: «summary», the CHANGELOG entry sits under the correct upcoming milestone, and the fallback is deliberately kept narrow so Linux/macOS resolution is untouched. 👍

No blockers, so this is a comment review rather than request-changes. There is however one real scope gap and a chunk of logic that duplicates helpers MvnArtifact already provides.

Should-fix

1. The reported command is still broken. getSnapshotBaseVersion(...) returns null for release versions, so the fallback only ever applies to --mode=snapshot. Plain ide upgrade on a non-SNAPSHOT installation resolves UpgradeMode.STABLE/UNSTABLE (IdeasyCommandlet#getConfiguredVersion), which yields a release version — and that path still produces the 404 from the issue. The issue's reproduction is "1. Install IDEasy on Windows on ARM. 2. ide upgrade", so as it stands fixes #1981 is only half true. See the inline comment on getMetadata.
2. Duplicated snapshot-version logic. PATTERN_TIMESTAMPED_SNAPSHOT and getSnapshotBaseVersion(String) re-implement MvnArtifact.SNAPSHOT_VERSION_PATTERN / MvnArtifact#isSnapshot() / MvnArtifact#getBaseVersion(), which already exist and are already exercised by the download-URL path. Both new members can be deleted — inline suggestion below.
3. The actual bug path has no test. All three new tests call the package-private resolveSnapshotClassifier(Document, String, String) directly. The wiring in getMetadata and the metadata-URL derivation are untested, which is why coverage moved only +0.02%. Per the TDD rule in AGENTS.md the first test should be the one that reproduces the bug — and SystemInfoMock + IdeTestContext#setSystemInfo + MvnRepositoryMock (WireMock-backed, already serves maven-metadata.xml from test resources) make that straightforward.
4. Probing metadata is not best-effort. If the extra maven-metadata.xml fetch fails, fetchXmlMetadata throws CliException("Failed to determine the latest version from ...") and aborts the whole upgrade with a message that no longer describes what was happening. It also means Windows ARM64 now always needs network in getMetadata, even when the artifact is already in the local .m2 repo.
5. Manual QA. CI has no windows-arm64 runner, so green checks prove nothing here. The -Dos.arch=arm64 simulation in the testing instructions exercises resolution but not actually running the x64 binary under emulation — this needs one real pass on Windows on ARM before merge.

PR hygiene

• The branch is BEHIND main (mergeStateStatus: BEHIND) — please update it before merge.
• Neither the PR nor #1981 has a milestone set; per documentation/contributing/DoD.adoc that needs to be set before the issue is closed.
• Minor: the CHANGELOG line restates the bug title ("ide update fails on windows@arm64") rather than the fix. Most neighbouring entries read as what changed, e.g. Fall back to windows-x64 when no windows-arm64 artifact is published.

Details and concrete suggestions inline.

[cap-juan]

Automated tests cover Windows ARM64 artifact resolution and x64 fallback. I could not perform a runtime validation on physical Windows ARM64 hardware, so execution under Windows-on-ARM emulation still needs manual verification before merge.