Malformed `--endpoint-url` fails with an opaque "Invalid URL" / retried "fetch failed" instead of a clear validation error

[Davidson3556]

Summary

A malformed API endpoint (--endpoint-url, TESTSPRITE_API_URL, or the credentials file api_url) is not validated, so it surfaces as an opaque or misleading error instead of a clear config error.

$ testsprite --endpoint-url "not a url" project list
Error: Invalid URL                       # exit 1 — raw new URL() throw, no guidance

$ testsprite --endpoint-url "localhost:3000" project list   # missing scheme
Error: fetch failed                      # "localhost:3000" parses as scheme "localhost:"
Service is temporarily unavailable. The CLI retries with exponential backoff; ...
# emitted only AFTER a full retry+backoff cycle — looks like a network outage

$ testsprite --endpoint-url "ftp://x.com" project list      # wrong scheme
Error: fetch failed                      # same misleading path

For a config typo, the operator gets either a bare Invalid URL (exit 1) or a fetch failed/UNAVAILABLE after the client wastes a retry cycle — neither points at the real problem.

Suggested fix

Validate the resolved endpoint is a syntactically valid http(s) URL in makeHttpClient (covers all three sources, both real and dry-run paths) and throw a typed VALIDATION_ERROR (exit 5) otherwise.

Important: unlike the --target-url guard (target-url.ts), this must not reject localhost / private addresses — the API endpoint legitimately points at self-hosted, local-dev, or mock backends (the test suite itself targets a http://localhost mock). Only malformed values (unparseable or non-http(s) scheme) should be rejected.

I have a PR ready for this.