compare the file scheme case-insensitively in isValid

[sahvx655-wq]

Chasing why an all upper case FILE: URL validated differently from its lower case twin led back to isValid. isValidScheme matches the scheme case-blind (it lower-cases before the allow-list check, and RFC 3986 3.1 makes schemes case-insensitive), but the file handling just below it tests "file".equals(scheme) twice, so a FILE: or File: scheme takes neither branch.

1. the empty-authority allowance is skipped, so a validator built for the file scheme rejects FILE:///etc/hosts while accepting file:///etc/hosts.
2. the drive-letter guard is skipped, so with ALLOW_LOCAL_URLS the authority FILE://C:/some.file is accepted although the byte-identical file://C:/some.file is rejected as it should be (testValidator276 already pins the lower case form as never valid).

Computed the file-scheme test once with equalsIgnoreCase and reused it in both places. Left unfixed the second case is a validation bypass: an allow-list keyed on the scheme lets a crafted upper case authority slip past the guard the lower case form is stopped by. Added testFileSchemeCaseInsensitive, which fails on master and passes with the change.

• 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.