http: set r.Pattern on dispatched requests for automatic route tagging

[raphael]

Summary

The default HTTP muxer now populates r.Pattern with "METHOD /path" on every dispatched request, following the Go 1.22+ convention established by http.ServeMux.

This enables observability middleware such as otelhttp (v0.65.0+) to automatically tag spans and metrics with the matched route — no per-handler wrapping required.

Problem

The otelhttp package removed WithRouteTag in v0.65.0, breaking the otel plugin which generated calls to that function. The upstream replacement is r.Pattern — otelhttp now reads it automatically after handler dispatch.

Since Goa uses a Chi-based muxer (not http.ServeMux), r.Pattern was never set, so otelhttp couldn't pick up the route.

Solution

A single change in mux.Handle: capture the original Goa pattern before Chi's wildcard rewriting and set r.Pattern inside the handler wrapper:

reqPattern := method + " " + pattern
// ... wildcard rewriting ...
m.Method(method, pattern, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    r.Pattern = reqPattern
    handler(w, r)
}))

Benefits over the old plugin approach:

• One place instead of N per-handler wrappers
• Covers all handlers uniformly — endpoints and file servers alike (the plugin only covered endpoints)
• No fragile template string surgery in a plugin
• Zero otelhttp dependency in generated or framework code — pure Go stdlib r.Pattern

The otel plugin has been deprecated in goadesign/plugins#242.

Fixes #3896

Test plan

• New TestRequestPattern — verifies r.Pattern is set correctly for simple paths, parameterized segments (/users/{id}), and wildcards (/files/{*path})
• All existing mux tests pass (TestMiddlewares, TestVars, TestResolvePattern)
• go test ./http/ green