Centralize OS and architecture capability validation

[brunoborges]

Summary

Centralize validation of operating-system and architecture combinations supported by each Java distribution.

Package capabilities are now declared and validated before installation, but platform and architecture support remains scattered across distributor implementations. Some installers validate locally, others pass the requested values to vendor APIs and report a generic version-not-found error, and diagnostic wording differs across distributions. Unsupported requests may therefore perform unnecessary network calls before failing and can obscure whether the version, OS, or architecture is the actual problem.

Proposed changes

• Define a typed capability model for supported operating systems and architectures per distribution.
• Normalize accepted architecture aliases in one place, including runner values and common user inputs such as amd64 to x64, ia32 to x86, and arm64 to the canonical architecture used by capability validation.
• Keep vendor-specific architecture translation separate from user-input normalization; for example, translate the validated canonical value to aarch64, i686, or another vendor API value only when constructing vendor requests.
• Validate the selected distribution, current OS, and requested architecture before cache lookup or network access.
• Produce a consistent error containing the distribution, requested OS and architecture, and the combinations supported by that distribution.
• Represent conditional support where necessary, such as architectures available only on certain operating systems or Java versions.
• Reuse the capability metadata in documentation and tests where practical to reduce drift.

Acceptance criteria

• Unsupported OS/architecture combinations fail before any vendor API or archive request.
• Architecture aliases resolve consistently across every distribution.
• Existing supported combinations retain their current vendor-specific request values.
• Errors distinguish unsupported platform combinations from unavailable Java versions.
• Contract tests cover every distribution and ensure the capability table matches installer behavior.
• Tests cover default runner architecture detection, explicit aliases, unsupported architectures, OS-specific restrictions, and version-dependent restrictions.
• End-to-end coverage includes at least one non-x64 architecture and one expected unsupported combination.

Motivation

A shared capability contract makes input behavior predictable, avoids unnecessary external requests, improves failure diagnostics, and prevents distributor implementations, documentation, and E2E matrices from drifting apart.