openapi3: remove map-iteration order leaks causing flaky tests

[cloudnativeninja]

Bug

Several sites iterate a Go map with for ... range and let the
randomized iteration order leak into observable output (error strings,
returned slices). When tests assert on that output — as refs_test.go
and issue513_test.go do with require.EqualError on the exact
extra sibling fields: [...] message — the assertion flakes whenever
the map holds 2+ keys. The same pattern produces subtler
non-determinism in openapi3filter and routers/gorillamux.

These are plausible contributors to the flakes noted in the recent
"openapi3: skip v3.1 load/validation flaky tests" commit (apis-guru
validation over specs with multiple sibling extensions on $ref
nodes, and expanded paths over enum variables).

Audit methodology

Wrote a small go/ast + go/types walker that flags every
RangeStmt whose operand has *types.Map type and whose body
appends to a slice or formats a string using the iteration variable.
The walker flagged 14 candidate sites across the repo; manual review
whittled those to 4 real order-leaks — the 10 others already sort
post-append (slices.Sort), short-circuit on a bool, or write only
into another map (order-independent consumers).

Fixes (one commit each)

1. openapi3/refs.tmpl — validateExtras (generated → openapi3/refs.go)

Root cause of the test flakes on the extra sibling fields assertion.

-		for ex := range x.Extensions {
+		for _, ex := range componentNames(x.Extensions) {

componentNames is the existing helper already used one loop above
for the sibling x.extra slice — it returns a sorted []string.
Regenerated refs.go via go generate ./...; fix propagates to all
9 generated *Ref.validateExtras methods (Callback, Example,
Header, Link, Parameter, RequestBody, Response, Schema,
SecurityScheme).

2. openapi3filter/req_resp_decoder.go — form-body schema check

for propName, propSchema := range schema.Value.Properties { ...
    return nil, fmt.Errorf("unsupported schema of request body's property %q", propName)

Returned the first invalid property found. With multiple invalid
properties, which one surfaced was random. Sort names before
iteration.

3. openapi3filter/req_resp_decoder.go — decodeSchemaConstructs

for name, prop := range schemaRef.Value.Properties { ...
    return fmt.Errorf("conflicting values for property %q", name)

Same pattern for the conflict-detection error.

4. routers/gorillamux/router.go — enum expansion

s := make([]string, 0, len(m))
for value := range m { s = append(s, value) }
var2val[name] = mapAndSlice{m: m, s: s}

Callers index s as mas.s[i%len(mas.s)] to build template path
parts, so different map orderings produced different sets of
expanded paths across runs (the outer parts slice is sorted, but
the set of generated parts depends on the enum permutation).
Added slices.Sort(s) after the append loop.

Behavior change

None beyond determinism. The set of properties/errors/paths produced
is identical; only the order is now stable (alphabetical).

Verification

• go generate ./... — no spurious diff beyond the 9 intended sites in refs.go.
• go build ./... — clean.
• go test -count=3 ./openapi3 — 5853 tests × 3 runs, 0 failures.
• go test -count=2 ./... — 4703 tests × 2 runs across 11 packages, 0 failures.
• go test -run "TestRefsExtras|TestIssue513" -count=100 ./openapi3 — 1200 runs, 0 failures (was flaky before).

The AST walker used for the audit is not included in this PR but can
be shared if you'd like it vendored as a lint check.