stdhttp: path parameter names starting with digits panic stdlib ServeMux #2306

Summary

When an OpenAPI spec defines a path parameter whose name starts with a digit (e.g. {1param}), the generated stdhttp server code panics during route registration because Go's http.ServeMux requires wildcard names to be valid Go identifiers.

Reproduction

Any OpenAPI spec with a path like:

/example/{1param}:
  get:
    parameters:
      - name: 1param
        in: path
        required: true
        schema:
          type: string

The generated code registers:

m.HandleFunc("GET /example/{1param}", wrapper.GetExample)

Which panics with: bad wildcard name "1param"

The middleware also extracts the value using the raw name:

n1param = r.PathValue("1param")

Root cause

SwaggerUriToStdHttpUri in pkg/codegen/utils.go strips OpenAPI style prefixes (., ;, ?, *) but passes through the raw parameter name without sanitizing it for stdlib mux compatibility. The stdhttp middleware template similarly uses {{.ParamName}} directly in r.PathValue() calls.

Other routers (Echo, Chi, Gin, Gorilla, Iris, Fiber) don't have this restriction — their routing libraries accept arbitrary parameter names.

Proposed fix

Both SwaggerUriToStdHttpUri and the stdhttp middleware template need to apply the same name sanitization that the Go type generator uses (prefixing digit-leading names with a character like N). They must agree on the sanitized name so route registration and PathValue extraction match.

Affected files:

• pkg/codegen/utils.go — SwaggerUriToStdHttpUri function (line ~652)
• pkg/codegen/templates/stdhttp/std-http-middleware.tmpl — r.PathValue("{{.ParamName}}") calls (lines 23, 26, 33)
• pkg/codegen/templates/stdhttp/std-http-handler.tmpl — route registration (line 52)

Context

Found by the multi-router parameter roundtrip test on the feat/param-cleanup branch. The test is currently skipped for stdhttp pending this fix.