fix(arm): honor PlatformIO registry version pins across ARM packages #1493

Context

ARM family orchestrators currently consume URL/archive overrides for selected framework packages, but registry versions in platform = <name>@<version> and platform_packages = <package>@<version> do not reach package resolution. The shared fbuild_config::parse_platform_packages_entry intentionally returns None for a bare version; family constructors then choose fbuild's const-pinned defaults. This is a successful-build substitution, not just a missing warning.

Confirmed representative repro (using the existing tests/platform/teensy41 board):

[env:teensy41]
platform = teensy@5.1.0
board = teensy41
framework = arduino
platform_packages =
    framework-arduinoteensy@1.159.0

Both teensy@5.1.0 and framework versions 1.159.0 / 1.160.0 are present in the PlatformIO registry. The focused parser test fbuild_config::platform_packages::tests::version_only_returns_none confirms that the explicit package pin produces no override. teensy_packages then takes its None branch and constructs TeensyCores::new, whose resolved framework is framework-arduinoteensy@1.160.0 from the 1.160.0 registry archive URL. The requested 1.159.0 is therefore replaced by 1.160.0. The same constructor selects toolchain-gccarmnoneeabi-teensy@1.110301.0; the repro does not request a toolchain version, so there is no requested toolchain version to compare. The platform version is warned about by ignored_version_pins, but ARM framework resolution does not resolve the PlatformIO platform registry package.

Proposal

Resolve valid PlatformIO registry aliases for ARM platform and platform_packages requests to the requested platform/package archive and its compatible dependency set; build using those packages. Fail before compilation only for unavailable versions, unsupported hosts, or genuinely unsupported inputs. Keep the fix at the shared parsing/resolution boundary where possible, and preserve the current URL/archive override behavior. Cover family-specific package names and layouts rather than assuming one framework mapping.

Families in this audit scope: RP2040/RP2350, STM32 (including Arduino Mbed/GIGA routing), SAM/SAMD/ClearCore, nRF52, Teensy, NXP LPC8xx, Apollo3, Renesas RA, and Silicon Labs.

PlatformIO alias requirement

Resolve short and owner-qualified platform/package aliases through PlatformIO registry metadata, including archive URL, SHA-256 and host-specific files. Apply platform_packages precedence over platform defaults and keep family-specific build layouts/flags aligned with the resolved version; a metadata server may provide the mapping without mirroring binaries.

Acceptance criteria

• RED: a focused Teensy resolution test or build using the ini above demonstrates that framework-arduinoteensy@1.159.0 currently resolves to 1.160.0 (and that teensy@5.1.0 does not resolve a platform registry package).
• GREEN: valid published registry aliases for each supported ARM family resolve the requested platform/package version and compatible host-specific dependencies and build with them; the Teensy 1.159.0 repro no longer selects 1.160.0. Unavailable or unsupported aliases fail before compilation, but refusal of a valid supported alias is not completion.
• Tests cover the family package mapping and the platform = name@version path, including toolchain/SDK pins where accepted.
• Existing URL/archive package overrides remain honored. Platform URL schemes outside the archive resolver's supported HTTP(S) archive form are identified as unsupported and are not treated as registry-version support.
• Build output or metadata identifies requested and resolved package versions.
• Unit tests: table-drive offline alias-to-payload fixtures for every ARM family named above (including the Teensy 1.159.0 counterexample), covering short/owner-qualified names, host files, framework/toolchain dependencies, and package-override precedence through the shared fbuild-core API. Keep each family adapter test focused on consuming the normalized payload rather than reimplementing registry lookup.

Decisions

• Keep the ARM scope in one child because the confirmed registry-version failure shares the same parser/resolver boundary across these families; framework defaults and package layouts remain family-specific test cases.
• Treat an explicit package version substituted by a family default as a correctness/reproducibility defect even when fbuild emits the A pinned platform version is silently ignored — in platform and in platform_packages #1407 warning.
• Use the existing Teensy 4.1 fixture for the minimal regression repro; its package registry includes adjacent versions, making the mismatch observable without conflating it with an unavailable version.
• Preserve URL/archive overrides; they are already parsed separately and are not evidence that registry semver pins work.

Related issues

• A pinned platform version is silently ignored — in platform and in platform_packages #1407 fixed warning visibility for ignored pins; it did not resolve them.
• audit: teensy / framework-arduinoteensy — does platform_packages override work? (parent #664) #680 audited Teensy URL-based framework overrides under tracking: platform_packages override silently ignored across framework packages (audit, sibling of #663) #664, not semver registry pins.

Core and ARM testing gate

• RED → GREEN: before adapter fixes, add a failing exact-payload assertion for each ARM family to the shared offline fbuild-core generic-path suite. Cover RP2040/RP2350, STM32 and Arduino Mbed/GIGA, SAM/SAMD/ClearCore, nRF52, Teensy, NXP LPC8xx, Apollo3, Renesas RA, and Silicon Labs. The Teensy 1.159.0 pin is a mandatory counterexample.
• For each path, assert short/owner-qualified/typed alias normalization, exact selected version and host-specific URL/SHA-256 or VCS ref, cache identity, manifest framework/SDK/toolchain dependencies, and explicit package override precedence. A syntactically valid unknown platform must still resolve core payload metadata before native dispatch rejects its build.
• Where an upstream registry platform manifest does not contain the Arduino framework required by fbuild's native adapter, assert a specific incompatibility error before compilation; do not substitute the adapter's pinned default or count that rejection as support for a valid compatible alias.
• Separate ARM adapter/build tests prove each family consumes the core result, preserves URL/archive overrides, and reports requested versus resolved identities. Shared core tests run offline in CI without PlatformIO or compiler downloads.