The iris RegisterHandlersWithOptions declared a Middlewares option but
never read it, so user-supplied middlewares were silently ignored.
Apply them via router.Use() before route registration, matching how
fiber treats its equivalent Middlewares option. The loop sits outside
the operations guard so middlewares register even for a spec with no
operations.

Adds a runtime regression test under internal/test/servers/middleware,
which fails against the previous template.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

All nine server wrapper templates bound a pass-through (non-JSON
content) header param by assigning params.X directly, then
unconditionally re-assigned params.X from a local variable that the
pass-through branch never set -- so the handler always received the
zero value. The JSON and styled branches bind through the local, which
is why the trailing assignment exists.

Assign the local in the pass-through branch instead, letting the
shared trailing assignment (and its optional-pointer handling) apply
uniformly to all three branches. The receiver templates already did
this correctly; the wrappers never got the same shape.

Adds a text/plain content header param to the parameter round-trip
suite, which fails on every backend without this fix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The fiber v2 and v3 wrappers built the required-header-missing message
with fmt.Errorf("...: %w", err), but in that branch the header was
simply absent -- err is nil (rendering "%!w(<nil>)" in the response)
or stale from a previously bound parameter, leaking an unrelated error
into the message.

Return the plain message instead, matching the fiber receiver template
and every other backend.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The fiber v2 and v3 wrappers handled a missing required pass-through
or JSON-content query parameter by writing c.Status(400).JSON(err) --
which marshals a bare error to "{}" -- and then also returning the raw
error, so fiber's default error handler ran again on the
already-written response and reported 500 for a client error.

Return fiber.NewError(400, ...) instead, matching every sibling
binding branch and the fiber receiver template.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The fiber v2/v3 and iris strict handlers reported errors returned by
the user's handler -- and failures while writing the response -- as
HTTP 400, conflating server-side failures with client errors. Every
other backend reports these as 500. Iris additionally wrote the
"unexpected response type" message without setting any status code,
producing an implicit 200.

Fiber now returns the raw error into fiber's error chain (matching
echo): the default error handler yields 500, custom app error handlers
receive the untouched error, and handlers that deliberately return a
*fiber.Error keep control of their status. Iris now uses
StopWithError(500, ...) for all three failure paths.

Adds runtime regression tests for fiber and iris asserting a handler
error surfaces as 500; both fail against the previous templates.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The shared strict template for chi, gorilla and stdhttp stored the
caller's StrictHTTPServerOptions verbatim, so leaving either error
handler nil (e.g. passing a zero-value options struct) caused a
nil-function panic on the first request or response error.

Fill in the same defaults NewStrictHandler already uses (400 for
request errors, 500 for response errors), matching what the gin strict
template does.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>