fix(server-utils): Skip Fastify 4xx errors raised before the reply status is set (#24924)

Since v11, `fastifyIntegration` always registers an `onError` hook
(#23460). Fastify runs `onError` hooks before it applies the error's
status to the reply, so for errors raised outside the route handler,
such as a request body that fails to parse
(`FST_ERR_CTP_EMPTY_JSON_BODY`, `FST_ERR_CTP_INVALID_JSON_BODY`),
`defaultShouldHandleError` still reads `reply.statusCode === 200` and
captures what is sent to the client as a 400. #18418 fixed the same
symptom for route handler errors upstream in Fastify 5.7.0, but only on
the diagnostics channel path.

When `reply.statusCode` is still the default 200, the default
`shouldHandleError` now resolves the status the same way Fastify's
`setErrorStatusCode` does: the error's `statusCode` or `status` if it is
at least 400, otherwise 500. This predicts the status Fastify is about
to send, and errors without a status still count as 500, so they are
still captured. A status already set on the reply takes precedence, as
before.

A custom `shouldHandleError` still receives `reply.statusCode === 200`
on this path. I left that alone, since changing what callbacks receive
is a separate decision.

Fixes #24926

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>