[StaticWebAssets] Replace opaque endpoint-manifest collision throw with a targeted BLAZOR107 diagnostic

[PureWeen]

Summary

When two static web assets resolve to the same target path, GenerateStaticWebAssetEndpointsManifest (and its sibling GenerateStaticWebAssetsDevelopmentManifest) crashed with an opaque InvalidOperationException: Sequence contains more than one element from a SingleOrDefault() call. The message named neither the target path nor the colliding assets, so there was no signal about which project or package produced the duplicate.

That opacity actively caused a misdiagnosis of #54779: with no provenance in the error, the natural instinct was to "fix" the SDK task that threw, rather than the upstream producer that generated the duplicate asset.

This PR replaces the throw at both call sites with a targeted BLAZOR107 diagnostic that names every colliding asset's provenance, so the next investigator (human or tooling) is pointed at the producer instead of the symptom.

Note

This is diagnostic hardening, complementary to — not a substitute for — the actual fix for #54779. The collision in that issue originates in the Microsoft.AspNetCore.Components.WebView package and is being addressed in dotnet/aspnetcore. This change ensures that any future producer-side target-path collision fails loudly with actionable provenance.

What changed

• GenerateStaticWebAssetEndpointsManifest.cs — the throwing site. ChooseNearestAssetKind(...).SingleOrDefault() becomes .ToArray(); if more than one asset is yielded, log BLAZOR107 (listing each asset) and continue; otherwise pick the single asset exactly as before.
• GenerateStaticWebAssetsDevelopmentManifest.cs — the same latent SingleOrDefault() pattern, given the same treatment.
• StaticWebAsset.ChooseNearestAssetKind — added an invariant comment documenting that yielding more than one asset means malformed producer-side input, and that callers must surface BLAZOR107 rather than silently collapsing the duplicates here.

Behavior is identical except on the error path: the > 1 branch fires in exactly the cases SingleOrDefault() previously threw; the single-asset and no-asset cases are unchanged.

Example diagnostic output

error BLAZOR107: More than one static web asset matched the target path
'_framework/blazor.modules.json' for asset kind 'Publish'. Each target path must
resolve to a single asset for a given asset kind. This usually means a referenced
project or NuGet package produced an asset that collides with one generated by this
project. Fix the project or package that produces one of these assets so that only a
single asset maps to this target path:
  - Identity='.../blazor.modules.json', SourceId='Microsoft.AspNetCore.Components.WebView', SourceType='Package', AssetKind='All', AssetMode='All'
  - Identity='.../jsmodules.build.manifest.json', SourceId='MyApp', SourceType='Discovered', AssetKind='All', AssetMode='All'

Tests

Two regression tests in GenerateStaticWebAssetEndpointsManifestTest:

• GenerateManifest_WhenMultipleAllAssetsCollideOnTargetPath_FailsWithBlazor107Diagnostic — reproduces the [Preview 6 regression] GenerateStaticWebAssetEndpointsManifest throws Sequence contains more than one element when a MAUI Blazor Hybrid project references a Razor class library and the BlazorWebView package #54779 collision shape (a package All asset + an app build All asset on the same target path) and asserts a single BLAZOR107 error naming the offending assets.
• GenerateManifest_WhenAllAndPublishAssetShareTargetPath_PicksPublishWithoutDiagnostic — guards against false positives: a normal All + Publish pair must still resolve to the Publish asset with no error.

Verified the regression test fails before this change (pre-fix logs a single uncoded error: "Sequence contains more than one element") and passes after. No regressions in the endpoints or development-manifest test classes.

Related to #54779.