Foundation-PR: pick the nightly by artifact presence, not build result

[romsi1983]

Installer and VSIX are permanently red on every Foundation PR targeting release/dev/monobuild:

Artifact WindowsAppSDK-NuGet-And-MSIX was not found for build 150121328.

150121328 is a 2026-06-18 nightly whose artifacts retention has purged (the artifacts API returns 0), so the download can never succeed. Everything else in the run is green, which makes the failure look unrelated to the PR.

Root cause: both step templates selected the nightly with runVersion: 'latestFromBranch', which filters candidates on the WHOLE-BUILD result. That is not the property the download depends on. The monobuild nightly is routinely failed purely because of its Test Gate stage while its Aggregate stage still publishes a correctly named WindowsAppSDK-NuGet-And-MSIX, so neither setting of allowFailedBuilds is right:

• false (today, from d46b72a) rejects roughly two months of perfectly usable artifact producers and falls back to the newest non-failed run, which is old enough to have been purged. The 10 most recent non-failed nightlies all report 0 artifacts, so there is no self-healing fallback on the branch.
• true (what d46b72a replaced) takes the newest run even when its Aggregate stage never produced the artifact - about a quarter of recent nightlies - or produced it under the 1ES <name>_failed_N rename, which 404s the same way.

Fix: resolve the build id from artifact presence instead. A new shared steps template probes the Build REST API for the newest completed run on the branch that publishes the exact artifact name, then downloads with runVersion: 'specific' / runId.

• Recency guard (maxNightlyAgeInDays, default 7): the search stops once it reaches older runs and fails with "No run of pipeline ... in the last N days publishes an artifact named ...", instead of a confusing 404 against a build id weeks in the past.
• Escape hatch: queue with a NightlyBuildIdOverride variable to pin a known-good nightly. The pinned build is validated the same way, so a stale pin also fails with a clear message.
• Exact-name matching, because the nightly also publishes <name>_sdl_analysis, which is not the payload.

The new template is referenced by a bare relative path, matching the existing same-repo includes in these files (PublishSymbol-Wrapper, SignPackageContents, EsrpCodeSigning-Wrapper), so it keeps resolving against this repo when the monobuild consumes these templates as @WindowsAppSDKFoundation. The monobuild passes SkipArtifactDownload: true and so compiles this block out entirely; only the standalone Foundation pipelines change behaviour.

Validated without queueing a build: all three files yaml-parse; the resolver script was extracted from the template and run against the live Build API, correctly picking 155530767 (the newest nightly that has the artifact) and correctly failing on the age guard, on an unknown artifact name, and on the expired 150121328 when pinned; and a template-parameter gate over build/** reports the same result on this tree as on the pristine branch, so no new "Unexpected parameter" surface was introduced.

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.