feat(http): api-versioning headers on all responses + multi-version handler support

[outofrange-consulting]

Summary

Combines #2661 and #2662 into a single rebased PR as requested.

Problem 1 — Versioning headers missing on error responses: API versioning headers (Deprecation, Sunset, Link, api-supported-versions) were only emitted on 2xx responses. The header writer ran as a postprocessor that codegen bypassed on early-return paths (validation failures, 404s, etc.).

Fix: Register an ApiVersionHeaderFinalizationPolicy that inserts the writer at middleware position 0 and uses Response.OnStarting to emit headers regardless of status code.

Problem 2 — No multi-version handler support: A handler couldn't serve multiple API versions — each version required a separate class.

Fix: Expand handler chains declaring multiple [ApiVersion] attributes into per-version clones during HttpGraph.DiscoverEndpoints, before policies run. Adds [MapToApiVersion] support for method-level version targeting within multi-version classes. The api-supported-versions header now reflects per-endpoint sibling version unions via ApiVersionMetadata.

Key changes:

• ApiVersionHeaderFinalizationPolicy — positions header writer above FluentValidation's short-circuit frame
• MultiVersionExpansion — clones chains per declared version with isolated metadata/attributes
• ApiVersionResolver.ResolveVersions — returns all declared versions (replaces single-version Resolve)
• Neutrality check ([ApiVersionNeutral]) now runs before the pre-assigned version guard to correctly handle fluent HasApiVersion() overrides
• Asp.Versioning.Abstractions floated to [10.0.0, 11.0.0)

Supersedes #2661 and #2662.

Open question

@jeremydmiller With multi-version handlers now available, should we update the RoutePrefix documentation to guide users toward one approach or the other (separate classes per version vs. multi-version handler with [MapToApiVersion])? Could help avoid confusion about when to use which.