fix: several host, IPv6, IDNA, and resolver correctness fixes

[OmarAlJarrah]

Summary

Seven independent, narrowly-scoped fixes found while reviewing the parser/serializer/resolver code against RFC 3986, WHATWG URL, and UTS-46. Each is a separate commit with its own test.

• Host normalization order. Uri reg-name normalization lowercased letters before decoding percent-encoded unreserved octets, so a percent-encoded uppercase letter (%41) never got folded — http://%41.com/ normalized to http://A.com/ instead of http://a.com/, and re-normalizing the result changed it again. Decoding now runs before lowercasing.
• IPv6 :: with no gap. The Uri-profile IPv6 scanner accepted a :: compression marker even when all eight groups were already explicit (e.g. [1:2:3:4:5:6:7::8]), silently treating it as equivalent to the same address with no compression. RFC 3986's IPv6address grammar has no such production; this case is now rejected.
• Missing invalid-credentials validation error. The WHATWG parser records non-fatal validation errors for a handful of quirky-but-accepted inputs (backslash-as-solidus, missing authority slashes, etc.), but never recorded one for userinfo (user:pass@) in the authority, even though the spec calls for it. Parsed output is unaffected; validationErrors() now includes it.
• toJavaUri() had no total counterpart. Bridging a Url/Uri to java.net.URI can throw an unchecked IllegalArgumentException when the WHATWG grammar accepts something the older RFC 2396 grammar java.net.URI uses does not (e.g. a literal | in a path). Added toJavaUriOrNull() for both types alongside the existing throwing form.
• IDNA's ASCII leniency was decided per whole domain instead of per label. By design, an all-ASCII domain keeps a malformed xn-- label as-is rather than rejecting it (existing browsers do this for compatibility). But that leniency was gated on the entire domain being ASCII, so xn--a.example kept a bad label while the otherwise-identical xn--a.café rejected the whole domain over the same label, just because a sibling label happened to be non-ASCII. The decision is now made per label, which is what the leniency was actually meant to describe.
• Resolver could fabricate an authority, and could throw instead of returning an error. Two related issues in reference resolution: (1) when dot-segment removal produced an authority-less path starting with //, recomposition didn't guard it the way the rest of the serializer does, so it silently re-parsed as if an authority were present; (2) merging a base's directory prefix with a long relative reference could exceed an internal length bound and throw a raw exception straight out of resolveOrNull/relativize, both of which are documented to never throw. Recomposition now applies the same guard used elsewhere, and the oversized-merge case now returns a proper error instead of throwing.
• Regenerated the API snapshot. Two of the fixes above add public API (a new ValidationError case, the two toJavaUriOrNull functions); the binary-compatibility snapshot has been regenerated to match.

Test plan

• Each fix has a dedicated unit test reproducing the original bug
• :kuri:jvmTest :kuri:ktlintCheck :kuri:detekt :kuri:apiCheck green
• :kuri:jsNodeTest and :kuri:wasmJsNodeTest green
• :kuri:macosArm64Test (native) green; every other native target's test code compiles cleanly
• IDNA conformance suite unaffected (confirms the IDNA fix didn't touch the shared UTS-46 engine, so no change needed to the Go conformance reference)