Default StaticWebAssetSpaFallbackEnabled to true in Microsoft.NET.Sdk.BlazorWebAssembly

[javiercn]

Summary

StaticWebAssetSpaFallbackEnabled defaults to false in Microsoft.NET.Sdk.StaticWebAssets.targets. For projects using Microsoft.NET.Sdk.BlazorWebAssembly it is the right default and every Blazor WASM consumer ends up having to opt in:

<PropertyGroup>
  <StaticWebAssetSpaFallbackEnabled>true</StaticWebAssetSpaFallbackEnabled>
</PropertyGroup>

Recent examples on the aspnetcore side that had to add it manually:

• dotnet/aspnetcore PR #66729 (commit b24ff65cc6) sets it in the standalone Blazor WebAssembly template, StandaloneApp, Wasm.Performance.TestApp, GlobalizationWasmApp, and removes the legacy SpaFallback.targets shim. It also drops MapFallbackToFile("index.html") from Microsoft.AspNetCore.Components.Gateway now that the SPA fallback is emitted as a {**fallback:nonfile} endpoint with Order=int.MaxValue in the static-asset manifest.

Proposal

Have Microsoft.NET.Sdk.BlazorWebAssembly (and any other WASM-flavored SDKs) default StaticWebAssetSpaFallbackEnabled to true so app authors don''t need to set it themselves and consumers of the published static-asset manifest (gateway, MapStaticAssets in a hosted server, etc.) get SPA-fallback routing without any extra wiring.

User opt-out remains via setting the property explicitly to false.

Why this matters

• The manifest-side support (StaticAssetDescriptor.Order, Order parsed at endpoint factory) shipped in dotnet/aspnetcore PR #65975 and the negotiation-matcher fix shipped in #65973. With those in place, the only remaining thing standing between a published WASM app and a working SPA fallback served by MapStaticAssets is this one MSBuild property.
• It removes the need for MapFallbackToFile("index.html") calls from every host that fronts a Blazor WASM app.

cc @javiercn