Bring the fiber and iris strict-server interface templates back into parity
with the canonical stdhttp template (`strict-interface.tmpl`). Four pieces of
drift were addressed:

1. Nullable / optional response-header serialization. Both templates now use
   the same three-way switch on `.IsNullable` / `.IsOptional` / default that
   PR #2301 introduced for stdhttp, so unspecified nullable values and nil
   optional pointers are skipped instead of being stringified into the wire
   header.

2. Response-header struct field types. The `{{$opid}}{{$statusCode}}ResponseHeaders`
   struct now uses `{{.GoTypeDef}}` (pointer/nullable-aware) rather than the
   raw `{{.Schema.TypeDecl}}`, matching the type that the typed-body Visit
   function expects.

3. `$ref` Text responses. The fixed-status-code + ref branch now matches
   Multipart and Text together (PR #2225), so `$ref` text responses alias
   directly to the component response type. Iris additionally drops its
   unconditional `type X string` short-circuit, which previously masked
   `$ref`, `$hasHeaders`, and `$fixedStatusCode` for any text response.

4. `$ref` name qualification (fiber only). Switch from `ucFirst` to
   `ucFirstWithPkgName` so external-ref response types carry their package
   qualifier, matching stdhttp and iris.

Regenerated fixtures under `internal/test/strict-server/{fiber,iris}/server.gen.go`
demonstrate the change for items (1) and (2); items (3) and (4) have no
existing fiber/iris fixture coverage.

The no-content `Visit*Response` branch still renders headers unconditionally
in all three templates (including stdhttp); that gap is tracked separately
(#2349) and not addressed here.

Fixes: #2331

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…2351)

The no-content branch of the three strict-server interface templates
(`strict-interface.tmpl`, `strict-fiber-interface.tmpl`,
`strict-iris-interface.tmpl`) was rendering response headers
unconditionally, missing the three-way `.IsNullable` / `.IsOptional` /
default switch that PR #2301 added to the typed-body branch.

Because the `{{$opid}}{{$statusCode}}ResponseHeaders` struct is shared
between the typed-body and no-content branches and uses
`{{.GoTypeDef}}` (since #2301 / #2331), an unset optional header field
is `*string(nil)` and an unspecified nullable header is a zero
`runtime.Nullable[T]`. The bare `fmt.Sprint(...)` in the no-content
branch was therefore stringifying these to `<nil>` / a typed
zero-value and emitting a junk header rather than omitting it. A
204-style response declaring an optional or nullable header — with
the caller leaving it unset — produced a wrong header value instead
of no header at all.

Apply the same three-way switch to the no-content branch in all
three templates so unset values are skipped, matching the typed-body
branch behavior and matching what callers expect for OpenAPI
`required: false` / `nullable: true` response headers.

Add regression coverage:

- `strict-schema.yaml` gains a `/no-content-headers` POST operation
  whose only response is 204 with `optional-header`
  (`required: false`) and `nullable-header` (`nullable: true`).
- `NoContentHeaders` handler stub returning an empty
  `NoContentHeaders204Response{}` is wired into all seven framework
  server implementations (chi, echo, fiber, gin, gorilla, iris,
  stdhttp).
- `NoContentHeadersOmitUnset` subtest added to the three `testImpl`
  copies (shared, stdhttp, fiber). Asserts both headers are absent
  from `rr.Header().Values(...)` when the response struct's header
  fields are left at their zero values.

The shared `testImpl` covers chi, echo, gin, and iris in one place;
stdhttp and fiber maintain their own copies because they live in
separate test files (stdhttp because of its own go.mod, fiber
because of its package boundary). Gorilla generates code but has no
test driver — the handler stub is still required so the generated
`StrictServerInterface` is satisfied.

Fixes: #2349

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>