feat(http): multi-version handlers + [MapToApiVersion] support

[outofrange-consulting]

Follow-up to #2633.

Summary

Wolverine.Http now expands handler chains that declare multiple API versions into one endpoint per version at bootstrap, before any IHttpPolicy runs. A single handler method can serve several versions (via repeated [ApiVersion] attributes or class-level [ApiVersion] declarations) while keeping per-version metadata, routes, and deprecation/sunset policies isolated to each clone.

[MapToApiVersion] is honoured on methods of classes that advertise multiple versions: the listed subset is registered, with strict validation that every mapped version exists at class level. Mixing [ApiVersion] and [MapToApiVersion] on the same method fails fast with a descriptive error.

Floats Asp.Versioning.Abstractions to [10.0.0,11.0.0).

Implementation notes

• HttpChain.CloneForVersion(ApiVersion, bool isDeprecated) is the per-version expansion primitive. Each clone gets a fresh MethodCall (sharing throws "Frame chain re-arranged" from JasperFx codegen). Per-clone OperationId is suffixed with _v{sanitised-version-string} to keep ASP.NET Core's "globally unique endpoint name" invariant; sanitisation is regex-based ([^A-Za-z0-9] → _) so date-based versions like 2024-01-01 produce _v2024_01_01 instead of breaking the rule.
• Each clone's metadata bag is filtered via a Metadata.Add callback that scrubs [ApiVersion] / [MapToApiVersion] attributes mismatched with the clone's own version. Without this, downstream OpenAPI tooling (Swashbuckle's WolverineApiVersioningSwaggerOperationFilter) would report each clone as implementing all sibling versions.
• MultiVersionExpansion.ExpandInPlace runs in HttpGraph.DiscoverEndpoints before any IHttpPolicy so middleware composition applies uniformly to all clones. Single-version chains are left to ApiVersioningPolicy.ResolveAttributes — no duplicated work.
• ApiVersionHeaderWriter now reads ApiVersionMetadata.ImplementedApiVersions from the matched endpoint when emitting api-supported-versions. Falls back to options.SunsetPolicies.Keys ∪ DeprecationPolicies.Keys for chains without per-endpoint metadata. The header therefore correctly reflects the sibling-version union for clones (e.g. v1 of a [ApiVersion("1.0"), ApiVersion("2.0"), ApiVersion("3.0")] handler emits api-supported-versions: 1.0, 2.0, 3.0).
• ApiVersioningPolicy.AttachMetadata seeds ApiVersionModel(declared, supported, deprecated) per clone by grouping all chains by (verb, route-without-version-prefix). Cross-class merging at the same route is intentional (matches Asp.Versioning conventions) and documented in the method's <remarks>.

Risk areas (touches core abstractions)

This PR modifies HttpChain.cs and HttpGraph.cs — please review the expansion-before-policy ordering and the per-clone MethodCall cloning rationale carefully. The Metadata.Add filter callback in CloneForVersion is also load-bearing for OpenAPI correctness.

Test plan

• MultiVersionExpansionTests — 13 unit tests (expansion mechanics, attribute filtering, sibling union, date-based versions, overlap detection across distinct handlers, [MapToApiVersion] single-version path, unversioned-alongside, cross-class union)
• MultiVersionResolverTests — 138 lines covering attribute resolution and [MapToApiVersion] validation
• multi_version_integration_tests — e2e via WolverineWebApi including multi_version_endpoint_emits_api_supported_versions_with_sibling_set (TDD-confirmed RED → GREEN), per-version deprecation propagation, isolated v4 attribute-only deprecation fixture (decoupled from Program.cs global Deprecate("1.0") to avoid false positives)
• ApiVersionResolverTests migrated to ResolveVersions API
• All ApiVersioning-suite tests green: 102/102

Sample app

• WolverineWebApi/ApiVersioning/CustomersMultiVersionEndpoint.cs — three versions on one class
• WolverineWebApi/ApiVersioning/CustomersV4AttributeDeprecatedEndpoint.cs — isolates per-version-attribute deprecation from options-driven deprecation

Docs

• docs/guide/http/versioning.md extended with multi-version + [MapToApiVersion] sections
• Per-version metadata semantics table including OperationId row (_v{sanitised-version-string})

[outofrange-consulting]

@jeremydmiller — could you take a look when you have a moment? This PR touches the core HttpChain and HttpGraph abstractions:

• HttpChain.CloneForVersion — new per-version expansion primitive. Each clone re-runs the HttpChain ctor (fresh MethodCall to avoid the JasperFx codegen "Frame chain re-arranged" exception) and applies a Metadata.Add callback to scrub sibling [ApiVersion] / [MapToApiVersion] attributes from each clone's metadata bag.
• HttpGraph.DiscoverEndpoints — MultiVersionExpansion.ExpandInPlace is invoked before any IHttpPolicy so middleware composition applies uniformly to all clones.

Two design calls I'd particularly value your eyes on:

1. Per-clone MethodCall cloning vs. lighter clone path — every other ctor side-effect (attribute application, configure-method discovery, parameter matching, implied middleware) re-runs per clone. For a 5-version handler that's 5× the bootstrap cost. Comment in HttpChain.cs:294 explains why the MethodCall itself must be fresh; the rest of the deep clone is conservative. Worth optimising or fine as-is?
2. Cross-class metadata merging at shared route — ApiVersioningPolicy.AttachMetadata groups by (verb, route-without-version-prefix) across distinct handler classes (intentional per Asp.Versioning conventions; documented in <remarks> and pinned by cross_class_chains_at_same_route_share_supported_versions). Want to confirm this matches your read of the contract before it ships.

Tests cover the load-bearing pieces (TDD RED → GREEN trail on multi_version_endpoint_emits_api_supported_versions_with_sibling_set); 102/102 ApiVersioning suite green.

[jeremydmiller]

@outofrange-consulting I'm going to let you deal w/ the merge conflicts:)

[outofrange-consulting]

Superseded by #2683 (combined with #2661 and rebased as requested).