feat(client): render x-stability-level in client Godoc - #2598

Closes #2483

What

When an operation sets the x-stability-level extension, the generated client methods now say so in their Godoc. This covers ClientInterface, Client, ClientWithResponsesInterface and ClientWithResponses, including the typed request-body variants:

paths:
  /pets:
    get:
      operationId: listPets
      summary: List pets
      x-stability-level: alpha

// ListPets List pets
//
// Corresponds with GET /pets (the `ListPets` operationId).
//
// This operation has been marked with the `alpha` stability level upstream (via `x-stability-level`).
ListPets(ctx context.Context, reqEditors ...RequestEditorFn) (*http.Response, error)

How

• extStabilityLevel = "x-stability-level" sits next to extDeprecationReason in pkg/codegen/extension.go.
• OperationDefinition.StabilityComment() reads the extension with the existing extString helper and trims it. It returns one comment line, or "" when the spec is nil, the extension is missing, the value isn't a string, or the value is empty.
• OperationDefinition.GenerateFunctionComment and RequestBodyDefinition.GenerateFunctionComment are the builders client_view.go uses for every client method comment. When that line is set, both append a // separator and then the line, in the summary and the no-summary branches.
• The value is rendered as-is. oasdiff defines draft, alpha, beta and stable, but the generator doesn't enforce them.
• Server and strict-server templates are unchanged. The issue is labelled client, so I kept this to the client. If you'd like the same line on the server interfaces too, I'm happy to extend it.

When an operation has no x-stability-level, output is byte-for-byte the same as before. Regenerating examples/ and internal/test/ touches no existing generated file.

Docs and example

• New row in the README "OpenAPI extensions" table.
• New x-stability-level section in docs/extensions.md, after x-deprecated-reason.
• New examples/extensions/xstabilitylevel/ (spec, config, generate.go and the generated gen.go), in the same layout as xdeprecatedreason. It has an alpha operation, a beta operation with a JSON body, and one operation without the extension.

Tests

• TestStabilityComment (nil spec, missing extension, alpha, surrounding whitespace, empty string, non-string value).
• New cases in TestOperationDefinition_GenerateFunctionComment and TestRequestBodyDefinition_GenerateFunctionComment, with and without a summary and with and without WithResponse.

Without the change, the new tests fail. StabilityComment is undefined, and with only the comment-builder hunks reverted, both GenerateFunctionComment tests fail. With the change, they pass.

Commands run (Go 1.25; make isn't available on my machine, so I ran what the Makefile targets run):

go vet ./pkg/... ./cmd/...
go test ./...                                       # root module
golangci-lint run ./...                             # v2.14.0, matches the Makefile pin: 0 issues
(cd examples && go generate ./... && go build ./... && go test ./... && golangci-lint run ./extensions/...)
(cd internal/test && go generate ./... && go test ./...)

Note for review: with my local Go 1.25 toolchain, go generate rewrites the base64 chunks of the embedded swaggerSpec in existing *.gen.go files. That only happens with my toolchain (compressor output differs between Go versions) and has nothing to do with this change: every changed line was one of those chunks. I reverted all of them, so this PR doesn't touch any existing generated file. The new example has no embedded spec.