Remove redundant app.UseAntiforgery() from Blazor Web templates

[DeagleGross]

CSRF protection is now on by default via the auto-injected CsrfProtectionMiddleware (Fetch Metadata based, #65127), so the explicit app.UseAntiforgery() in the Blazor Web templates is redundant. This removes it from both variants (Program.cs and Program.Main.cs).

Why the middleware change is needed

EndpointMiddleware throws "a middleware was not found that supports anti-forgery" when an endpoint requires antiforgery but no antiforgery middleware recorded that it ran (a marker in HttpContext.Items). With UseAntiforgery() gone, the auto-injected CsrfProtectionMiddleware is the only thing that can set that marker — but it previously set it only when an endpoint was already matched.

That breaks re-execute: UseStatusCodePagesWithReExecute / UseExceptionHandler re-run the request through a fresh routing branch that bypasses the auto-injected middleware, so it only runs once on the original request. If that request is a 404 (no endpoint) or hits a DisableAntiforgery() endpoint, the marker never gets set, and re-executing into an antiforgery-required page (e.g. a Razor Component) throws.

[Copilot]

Pull request overview

This PR removes the explicit app.UseAntiforgery(); call from the Blazor Web C# template’s two Program.cs variants, intending to rely on the newer CSRF middleware behavior instead of the legacy antiforgery middleware.

Changes:

• Removed app.UseAntiforgery(); from the top-level statements template Program.cs.
• Removed app.UseAntiforgery(); from the Main-style template Program.Main.cs.

Show a summary per file

File	Description
src/ProjectTemplates/Web.ProjectTemplates/content/BlazorWeb-CSharp/BlazorWebCSharp.1/Program.cs	Removes UseAntiforgery() from the template pipeline.
src/ProjectTemplates/Web.ProjectTemplates/content/BlazorWeb-CSharp/BlazorWebCSharp.1/Program.Main.cs	Removes UseAntiforgery() from the template pipeline (Main-style).

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 2

[DeagleGross]

test failure in aspnetcore-template-tests-pr also related to #67174

[BrennanConroy]

This change hurts perf for non-endpoint code paths. e.g. Our plaintext benchmarks now allocate billions of bytes per second instead of a previous ~5m bytes per second.

context.Items is lazily initialized, so by accessing it every time a request comes in creates a bunch of extra allocations:

[DeagleGross]

Thanks for noticing this Brennan, here is the fix: #67488