Add `RoutePattern` property to `ApiDescription`

[captainsafia]

Background and Motivation

ApiDescription today exposes only RelativePath as a string. Documentation tooling often has to re-parse that text to reconstruct routing details that endpoint routing already knows. This leads to mismatches, especially when templates use special prefixes (like ~) or when constraints/defaults can’t be inferred from the string. The goal here is to make the routing engine’s authoritative RoutePattern available to tools that build OpenAPI documents, generate API overviews, or analyze routes. Existing behavior of RelativePath remains unchanged.

#64408 surfaces the canonical RoutePattern from RouteEndpoint (and from attribute routes). This gives documentation generators a reliable, structured view of the actual routed pattern and eliminates re-parsing heuristics.

Proposed API

namespace Microsoft.AspNetCore.Mvc.ApiExplorer;

public class ApiDescription
{
+    public Microsoft.AspNetCore.Routing.Patterns.RoutePattern? RoutePattern { get; set; }
}

Usage Examples

var pattern = apiDescription.RoutePattern ?? RoutePatternFactory.Parse(apiDescription.RelativePath!);

Alternatives

• We could instead store the RoutePattern in EndpointMetadata for implementations to dig up but it feels appropriate to have it at the top-level, especially if RelativePath is already there.

Risks

• Nullability: Property is marked as nullable to support binary compute. Some providers won’t set RoutePattern; fallbacks need to be set in consuming code.
• Layering: Microsoft.AspNetCore.Mvc.Abstractions now has a dependency on Microsoft.AspNetCore.Routing. It already has a dependency on Microsoft.AspNetCore.Routing.Abstractions.

[dotnet-policy-service]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.