[StaticWebAssets] Add agent triage guidance + reasoning eval for endpoint-manifest collisions

[PureWeen]

What this adds

Triage knowledge + a reasoning eval for the Static Web Assets SDK failure mode
InvalidOperationException: Sequence contains more than one element at
ChooseNearestAssetKind(...).SingleOrDefault() in GenerateStaticWebAssetEndpointsManifest
(and the identical pattern in GenerateStaticWebAssetsDevelopmentManifest).

This is documentation, code comments, and an eval only — no functional/runtime change. Six files,
all under src/StaticWebAssetsSdk/:

• AGENTS.md — a "Triage Heuristic": the crash site is never the fix, and "blame the producer" is only
  half-right. Localize where the surplus asset is born and prevent it there. The durable fix makes the
  producing package's fallback conditional so exactly one asset ever lands on the route; an SDK-side
  carry-forward that re-applies the build-time group resolution at publish is an acceptable-but-superseded
  alternative. Do not soften the throwing task, do not retype the package asset as Framework while
  still emitting it unconditionally, and do not add a consumer-scoped Remove in the publish targets
  (the publish group filter is consumer-scoped and structurally cannot resolve a package-owned group).
• Architecture.md — documents deferred groups, why the build manifest retains all variants, and the
  conditional-package-fallback fix vs. the superseded SDK carry-forward.
• Code comments at StaticWebAsset.ChooseNearestAssetKind and the SingleOrDefault throw site, pointing
  readers at the durable fix.
• evals/ — a reasoning eval (corrected fixture from the real failing binlog + a tiered rubric) that
  measures whether this guidance moves a fresh agent past the symptom-site, unconditional-package-retype,
  consumer-scoped-Remove, and downstream-de-duplication answers to the conditional package fix.

Background: the real case (#54779)

A .NET MAUI Blazor Hybrid app referencing Microsoft.AspNetCore.Components.WebView + a Razor Class Library
with JS modules built fine but failed to publish, because the package's fallback
_framework/blazor.modules.json survived alongside the app's own modules manifest — two assets on one route.

The fix that landed is in the package, not the SDK: dotnet/aspnetcore#67375 (merged; backport
dotnet/aspnetcore#67401) makes the WebView blazor.modules.json fallback conditional (materialized
only when the consumer contributes no JS modules of its own). A candidate SDK-side carry-forward,
#54941, was built and empirically verified to work but was not merged (it compensates
downstream rather than preventing the second asset).

Why this lives in dotnet/sdk (even though the fix shipped in aspnetcore)

• The throwing task (GenerateStaticWebAssetEndpointsManifest) and ChooseNearestAssetKind exist only
  in dotnet/sdk — the code comments can't live anywhere else.
• The crash surfaces in SDK code; a future engineer debugging it starts here. The eval fixture is a
  dotnet/sdk binlog.
• This failure mode is general across all Static Web Assets scenarios (Blazor WASM, Razor, MAUI Hybrid);
  WebView/blazor.modules.json is just the worked example. General triage guidance belongs in the general
  (SDK) location and points to the package-side fix.

The fix's home repo (aspnetcore) is independently protected by the regression test suite added in #67375.

Verification

The conclusion the eval is calibrated to was empirically verified: on a genuinely pre-fix SDK, swapping only
the WebView package between runs reproduces the crash with the public package and resolves it (one asset, real
content) with the conditional-fallback package — including on a real dotnet new maui-blazor app against the
official preview.6 toolchain, with no SDK change.

---

Draft for review — feedback welcome on framing, repo placement, and the eval rubric.