wasmtime serve ignoring scheme in absolute-form requests

Thanks for filing a bug report! Please fill out the TODOs below.

**Note: if you want to report a security issue, please read our [security policy](https://bytecodealliance.org/security)!**

### Test Case

https://gitlab.com/sampointon/wasmtime-url-print

### Steps to Reproduce

0. Check out the above repository.
1. `cargo build --target wasm32-wasip2`
2. `wasmtime serve target/wasm32-wasip2/debug/wasmtime-url-print.wasm -S cli=y`
3. In a new terminal, manually send a HTTP/1.1 request with a scheme that's not `http` e.g. via netcat - example log (note the request line is in absolute-form):

```
$ nc localhost 8080
GET https://foo.example/bar HTTP/1.1
Host: baz.example

HTTP/1.1 200 OK
content-type: text/plain
content-length: 22
date: Fri, 29 Aug 2025 17:48:48 GMT

http://foo.example/bar
```

### Expected Results

The `https` scheme in the request would be preserved.

### Actual Results

The scheme was forcibly set to `http`.

(I do note, happily, that it's doing the right thing and ignoring Host in this instance, so it's not all bad.)

### Versions and Environment

Wasmtime version or commit: 36.0.2

Operating system: Fedora 42

Architecture: x86_64

### Extra Info

[RFC 9112, section 3.3, 'Reconstructing the Target URI`](https://www.rfc-editor.org/rfc/rfc9112.html#name-reconstructing-the-target-u):

> The target URI is the [request-target](https://www.rfc-editor.org/rfc/rfc9112.html#request.target) when the request-target is in [absolute-form](https://www.rfc-editor.org/rfc/rfc9112.html#absolute-form). In that case, a server will parse the URI into its generic components for further evaluation.

The current behaviour is entirely explained by [line 742 in `serve.rs`](https://github.com/bytecodealliance/wasmtime/blame/0744262f79e235b172331f5ba1a2c43b5aedcbfb/src/commands/serve.rs#L742), which is hard-coding the scheme to `http`.

I see that there's already been some back and forth on this in #8923 and #8878, but the present behaviour is simply wrong according to the spec.

wasmtime should probably defer to the scheme provided by hyper (which I've verified is correct in this case) on the basis that hyper sees the actual request line and can follow the guidance in RFC 9112 section 3.3 depending on whether it's in absolute-form or origin-form. Keeping around a scheme and authority _and_ a `request::Parts` struct that has its own scheme and authority in `HostIncomingRequest` seems weird and likely to be a bug magnet.

In practice, most requests in the wild will be origin-form, but I'm getting annoyingly snagged on this because I'm trying to do some local testing of some code that's unhappy if the request URLs aren't as it expects them to be, and I'd like to avoid having to spin up any infrastructure (e.g., DNS, certs, reverse proxies...) for that purpose. This sort of use-case (local testing of `wasi-http` components in a non-prod environment) seems to be squarely in the domain of `wasmtime serve`, so it would be useful if it was easy to 'fake' input URLs by using absolute-form requests.