Validate path, query and fragment for authority-less file URLs

[sahvx655-wq]

isValid returns as soon as it sees a file: scheme with a blank authority, and that return sits above the line calling isValidPath, isValidQuery and isValidFragment. Every ordinary file URL has no authority, since URI.getRawAuthority() is null for file:/x and file:///x alike, so for a validator configured with the file scheme that whole stage is unreachable. I went looking after checking whether the percent-encoded traversal guard from VALIDATOR-383 held across schemes: isValid("file:///../../etc/passwd") and isValid("file:///..%2f..%2fetc/passwd") both come back true, while the byte-identical path written under an authority, file://localhost/../../etc/passwd, is correctly rejected. The option flags behave the same way, so file:///tmp/a//b passes with ALLOW_2_SLASHES off and file:///tmp/x#frag passes with NO_FRAGMENTS on.

The special case exists only to excuse a file URL from carrying an authority, so I have narrowed it to skip the authority check alone rather than to leave the method. Keeping the decision in isValid means every scheme reaches the same three per-part checks; moving containment out to callers would leave the hole open for anyone who configures the file scheme, and an application that normalises a validated file: URL into a filesystem path is exactly where that gets expensive. One deliberate behaviour change worth flagging: an opaque URI such as file:etc/passwd has a null raw path and is now rejected, which is what http:example.com already does. The existing file expectations in testValidator276, testValidator391FAILS and testValidator391OK are unchanged, and both added tests fail without the runtime change.

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.