fix(isByteLength): handle unpaired surrogates instead of throwing

[sarathfrancis90]

isByteLength throws a URIError instead of returning a boolean when the input contains an unpaired surrogate:

validator.isByteLength('\uD835', { max: 3 }); // URIError: URI malformed
validator.isEmail('\uD835');                  // URIError (isEmail runs the local part through isByteLength)

encodeURI() rejects unpaired surrogates, so the byte-count line blows up. Every other validator just returns false on this kind of input, so the throw is both surprising and a small hazard when validating untrusted strings.

The fix replaces unpaired surrogates with U+FFFD before encoding — that's the same substitution a UTF-8 encoder makes (3 bytes), so the byte count stays correct and valid surrogate pairs are left exactly as they were. I added a regression test for both isByteLength and isEmail; the full suite passes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (7fdc788) to head (9492b89).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2742   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2587      2595    +8     
  Branches       656       659    +3     
=========================================
+ Hits          2587      2595    +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sarathfrancis90]

Flagging that this overlaps with #2822, which fixes the same encodeURI throw. The semantics end up identical — an unpaired surrogate counted as the 3-byte U+FFFD — the difference is that I sanitize the string and keep encodeURI, while #2822 replaces it with a direct UTF-8 byte count. That one also avoids building the intermediate encoded string, so it is arguably the better end state.

This one has been open since early June and is green, but I have no stake in which lands. Happy to close it if you prefer the #2822 approach, or to rebase mine. I just did not want two PRs sitting on the same function without anyone saying so.