http-get with malformed URL fails silently instead of throwing an actionable error

## `http-get:` with malformed URL fails silently instead of throwing an actionable error

**Version:** `wait-on@9.0.10`

### Description

When a malformed resource URL is passed (e.g. `http-get:localhost:...` instead of `http-get://localhost:...`), `wait-on` times out without ever indicating the root cause. The error is swallowed and the process exits with a generic timeout, making the bug extremely hard to diagnose.

### Steps to reproduce

**1. Run with a malformed URL (missing `//`):**
```shell
npx wait-on --timeout 10s http-get:localhost:8090/management/health
```

Output:
```
Error: Timed out waiting for: http-get:localhost:8090/management/health
at .../wait-on/lib/wait-on.js:131:31
...
```

**2. Run the same command with verbose logging:**
```shell
npx wait-on --timeout 10s -v -l http-get:localhost:8090/management/health
```

Output (verbose only):
```
waiting for 1 resources: http-get:localhost:8090/management/health
making HTTP(S) get request to url:http:localhost:8090/management/health ...
HTTP(S) error for http:localhost:8090/management/health AxiosError: Invalid URL: missing "//" after protocol
# repeats until timeout
```

**3. Correct URL works as expected:**
```shell
npx wait-on --timeout 10s http-get://localhost:8090/management/health
```

### Expected behavior

When the URL is structurally invalid (Axios itself throws `Invalid URL: missing "//" after protocol`), `wait-on` should surface that error immediately and exit with a descriptive message — not silently retry until the timeout expires.

### Actual behavior

The `AxiosError` is caught internally and treated as a transient failure, so `wait-on` keeps retrying until it times out. Without `--verbose`/`--log`, the underlying cause is completely invisible.

### Why this matters

This makes `wait-on` timeouts very difficult to debug in CI environments, where verbose logging is typically not enabled. A permanent error (invalid URL) should be distinguishable from a transient one (service not yet available) and should fail fast.

Reproduce the malformed and corrected commands, then inspect lib/wait-on.js around line 131 and the HTTP request path used by the http-get resource. Done means a structurally invalid URL exits promptly with an actionable error, while transient HTTP failures can still retry and valid URLs continue to work.

Written by the indexing model from the issue text.