[StaticWebAssets] Fix endpoints manifest crash when an All and a more specific asset share a target path (#54779)

[PureWeen]

Fixes #54779

Regression (Preview 6)

A MAUI Blazor Hybrid app that references a Razor class library and the Microsoft.AspNetCore.Components.WebView (BlazorWebView) package fails to build with:

GenerateStaticWebAssetEndpointsManifest ... Sequence contains more than one element

Root cause

Three static web assets map to the same target path _framework/blazor#[.{fingerprint}]?.modules.json:

• an All asset coming from the BlazorWebView package,
• an All project build JS-modules manifest, and
• new in Preview 6, a Publish project publish JS-modules manifest.

StaticWebAsset.ChooseNearestAssetKind surfaced the "two All assets" ambiguity eagerly (it yielded both and breaked) before it ever reached the more specific Publish asset, so the consumer's SingleOrDefault() threw. GenerateStaticWebAssetEndpointsManifest itself is unchanged — the new publish manifest changed the input to it.

Fix

Defer the multi-All decision: track up to two All candidates and only surface them (so the caller can still error on a genuine ambiguity) when no more specific Build/Publish asset is present in the group. A more specific asset that appears after the All assets now correctly wins. This also fixes the identical latent path in GenerateStaticWebAssetsDevelopmentManifest — the only other caller of ChooseNearestAssetKind.

Testing

• Added GeneratesPublishManifest_WhenAllAndPublishAssetsShareTargetPath_PrefersPublishAsset, which reconstructs the exact 3-asset group. It throws Sequence contains more than one element before the fix and passes after, producing a single endpoint sourced from the publish manifest.
• Existing GenerateStaticWebAssetEndpointsManifestTest (5), GenerateStaticWebAssetsDevelopmentManifestTest (23), and GenerateStaticWebAssetsManifestTest (19) all still pass.