Resolve files when absolute path is used, returns exception

### Version

io.vertx:vertx-core:4.5.30

### Context

When using Vertx, with PemTrustOptions for example, during the execution of the code, Vertx tries to load all the application properties from the quarkus classpath using the FileResolverImpl.

When this file is an absolute path reference, an exception is thrown. When a relative file is used, it works, but will represent other issues in the code.

Refering to line [147](https://github.com/eclipse-vertx/vert.x/blame/5a9bafbc965e5082ad6e6fdb2867fea2d66a0226/vertx-core/src/main/java/io/vertx/core/file/impl/FileResolverImpl.java#L147)

This method also scans the entire classloader and starts to resolve all files.
But the resolve will generate an incorrect `subResource` reference in line [267](https://github.com/eclipse-vertx/vert.x/blame/5a9bafbc965e5082ad6e6fdb2867fea2d66a0226/vertx-core/src/main/java/io/vertx/core/file/impl/FileResolverImpl.java#L267)

### Steps to reproduce

(minimal DemoResolve project in attachment [demoResolve.zip](https://github.com/user-attachments/files/30701396/demoResolve.zip))

1. Project containing only 1 resource file `application.yml` in `src/main/resources`
2. Test containing 1 `@QuarkusTest`
3. The test will try to resolve the (absolute) `/application.yml` file
4. Run test > gives exception

When changing
`fileResolver.resolveFile("/application.yml");`
to
`fileResolver.resolveFile("application.yml");`
it does not give an exception.

Problem lies in the fact that in this example, QuarkusTest writes an empty application.properties to a temp workfolder (e.g. `%TEMP%/startup-override9955225914473382599`)
The absolutePath will then find the startup folder (url) but reference is with a fileName '/' instead of `url.getPath()` which results in:
`//application.properties` > does not exist
instead of

`%TEMP%/startup-override9955225914473382599/application.properties`

### Do you have a reproducer?

_No response_

Start with vertx-core/src/main/java/io/vertx/core/file/impl/FileResolverImpl.java, especially the referenced lines 147 and 267. Reproduce the failure using the attached demoResolve project and its absolute /application.yml lookup, then verify that the generated temporary application.properties path resolves correctly without the exception.

Written by the indexing model from the issue text.