fix: guard shouldCompress against non-string Content-Type

[gnotos]

Checklist

• [x ] run npm run test && npm run benchmark --if-present
• [ x] tests and/or benchmarks are included
• documentation is changed or added
• [ x] commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

Follow-up to #331.

While investigating that issue I found that shouldCompress assumes type is always a string:

js
const data = mimedb[type.split(';', 1)[0].trim().toLowerCase()]

Any non-string value throws a TypeError there. Calling the function directly:

"application/force-download"   -> false
["application/force-download"] -> TypeError: type.split is not a function
123                            -> TypeError: type.split is not a function
undefined                      -> TypeError: Cannot read properties of undefined

To be clear about scope: I could not reproduce this through an actual HTTP request on current main. Fastify appears to drop an array Content-Type before the onSend hook runs, so a non-string value never reaches shouldCompress on that path. I've posted the details in #331 — the originally reported crash does not seem reproducible on v9.2.0.

This PR is therefore a defensive guard rather than a crash fix: a single early return that makes the function's contract explicit and its behaviour consistent for any non-string input. The test covers the array Content-Type path end to end.

Happy to close this if you'd rather not add a guard for an unreachable path.

[mcollina]

Can you fix linting?