fix: add type safety to res.location to prevent encodeUrl crash

[ST4RKJR]

res.location() currently passes the value directly into encodeUrl(url).
If url is not a string (e.g., null, undefined, numbers, objects), this
causes a TypeError and crashes the response.

This PR adds a small input guard that normalizes the value using
String(url ?? ''), ensuring encodeUrl always receives a valid string
and preventing runtime crashes.

This is a code-only, backward-compatible safety improvement.

[ST4RKJR]

Hi maintainers 👋
This PR adds a small safety improvement to res.location() to prevent encodeUrl() from throwing on non-string input.
Happy to update anything if needed. Thanks for reviewing!

[krzysdz]

So now invalid inputs will be quietly ignored without a trace? That doesn't sound like a good idea. While I understand that getting errors is annoying, it is much easier to debug problems if they are clearly signalled.

[ST4RKJR]

So now invalid inputs will be quietly ignored without a trace? That doesn't sound like a good idea. While I understand that getting errors is annoying, it is much easier to debug problems if they are clearly signalled.

Thanks for the feedback! You're right — silently coercing invalid values
could hide mistakes and make debugging harder. I updated the PR to throw
a descriptive TypeError instead when res.location() receives a
non-string value. This makes the behavior explicit and avoids unexpected
silent failures.

Happy to adjust further if needed!

[ST4RKJR]

Thanks for the feedback — the previous version was too strict and didn't
match existing Express behavior. I've updated res.location() to:

• accept URL instances,
• coerce all non-string inputs using String(),
• avoid silent ignoring of invalid values,
• and maintain backward compatibility.

This now aligns with the expectations in test/res.location.js.