Stream large multipart uploads through a MultipartReader endpoint parameter

[erdtsieck]

Wolverine.Http has no way to stream a large upload. IFormFile, IFormFileCollection, IFormCollection and [FromForm] all go through Request.Form, which buffers the whole body before the endpoint runs (in memory up to 64 KB per file, on disk beyond that). ASP.NET Core's answer is streaming with a MultipartReader. You can do that today with a raw HttpRequest parameter, but then every endpoint reimplements the content-type check, boundary parsing and limits.

This PR lets an endpoint take a MultipartReader:

[DisableRequestSizeLimit]
[RequestFormLimits(MultipartBodyLengthLimit = long.MaxValue)]
[WolverinePost("/upload/stream")]
public static async Task<string> Upload(MultipartReader reader, CancellationToken cancellationToken)
{
    while (await reader.ReadNextSectionAsync(cancellationToken) is { } section) { ... }
}

What the parameter does:

• Never touches Request.Form. The reader wraps the raw request body.
• Same limits as Request.Form. It reads the registered FormOptions and applies the endpoint's IFormOptionsMetadata ([RequestFormLimits]) on top, following FormFeature: boundary length, header count/length, and MultipartBodyLengthLimit as the per-section BodyLengthLimit.
• Error responses. A non-multipart request gets a 415, like the JSON body path. A missing or oversized boundary gets a 400 with ProblemDetails.
• Metadata. The endpoint advertises multipart/form-data in Accepts. It counts as a form endpoint for AutoAntiforgeryOnFormEndpoints(), since the CSRF exposure is the same.
• Startup failures. Combining the reader with IFormFile, [FromForm] or a JSON body fails at startup, because the body can only be read once. So does putting it on a GET or HEAD (the existing Guard against HTTP endpoints that advertise a request body they cannot receive (the #3630 failure class) #3648 guard). Middleware that also takes a MultipartReader gets the same instance.
• Size limits need no new code. [DisableRequestSizeLimit] / [RequestSizeLimit] already reach the endpoint metadata, and ASP.NET Core's EndpointRoutingMiddleware applies them. The tests' log shows it trying ("This server does not support the IHttpMaxRequestBodySizeFeature" under TestServer).

Not covered: F# codegen for the new frame. The existing IFormFile frames don't have it either. OpenAPI shows no schema for the parts, because the endpoint decides what it reads.

Docs: a new Streaming Large Uploads section in guide/http/files.md, covering the limits and the antiforgery caveat. Send the token in a header: without one, ASP.NET Core's antiforgery middleware reads the form, which buffers the body you meant to stream.

Tests

streaming_multipart_uploads covers:

• sections read in order, a 100 KB file included
• the form is never buffered: IFormFeature is still null after reading. I checked that this probe fails against an IFormCollection endpoint.
• [RequestFormLimits] reaches the reader
• the 415 and 400 responses
• the Accepts, size-limit and antiforgery metadata. The antiforgery test fails without the one-term change.
• the startup guards

The full Wolverine.Http.Tests suite passes locally: 1084 passed, 10 skipped.