Nicer Multipart Payloads?

### Description

We currently have codes like this:
```swift
func createThing(
_ input: OpenAPI.Operations.createThing.Input
) async throws -> OpenAPI.Operations.createThing.Output {
guard case let .multipartForm(payload) = input.body else {
throw Abort(.badRequest, reason: "Missing multipart form data.")
}

var title: String?
var subtitle: String?
var kind: Kind?

for try await part in payload {
switch part {
case let .title(payload):
title = try await payload.payload.body.collectAsString(upTo: 1024)
case let .subtitle(payload):
subtitle = try await payload.payload.body.collectAsString(upTo: 1024)
case let .kind(payload):
let kindString = try await payload.payload.body.collectAsString(upTo: 1024)
kind = Kind(rawValue: kindString)
default: break
}

guard let title else {
throw Abort(.badRequest, reason: "Title is required")
}
guard let kind else {
throw Abort(.badRequest, reason: "Kind is required")
}

let thing = Thing(
title: title,
subtitle: subtitle,
kind: kind
)
...
}
```

The code ... looks pretty redundant / bad ...
What can we do to avoid this kind of redundant code?
I can see how it can be hard to handle with multipart streaming APIs, but it's still pretty suboptimal ...

### Reproduction

-

### Package version(s)

generator 1.7.0
runtime 1.8.0

### Expected behavior

To not need to declare variables like `title` 4 different times just to initialize an struct with.

### Environment

6.0.3 RELEASE

### Additional information

_No response_

The issue names no files or tests; start by locating the generated Swift server multipart handling and the runtime's streaming multipart APIs. Define a concrete API shape that reduces repeated local variables while preserving required-field validation, then verify the generated handler and multipart behavior with the project's existing tests.

Written by the indexing model from the issue text.