Timing-fetch errors from GitLab API abort test run entirely, even for transient failures

splitic test fetches per-test timing data from a previous pipeline's test_report API endpoint before running any tests, to balance parallel shards (internal/timings/gitlab/gitlab.go). If that fetch fails with anything other than "no timing data available," internal/cmd/test/command.go treats it as fatal:

if err != nil {
    fmt.Fprintln(os.Stderr, "error collecting timing information:", err)
    os.Exit(1)
}

This means a transient network hiccup talking to gitlab.com/api/v4 — e.g. a ResponseHeaderTimeout (only 10s, set in the http.Client in gitlab.go) — kills the whole test job before a single test executes. No tests run, no JUnit report or artifacts are produced, and the job fails looking like a test infra issue rather than an API blip.

Observed in gitlab-runner CI, e.g. https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/15163231209:

$ splitic test -flaky ... -tags integration ./... -- -timeout 55m
error collecting timing information: performing timing request:
  Get "https://gitlab.com/api/v4/projects/250833/pipelines/2648455886/test_report":
  http2: timeout awaiting response headers

This is one of several distinct causes behind frequent Windows integration test job failures in gitlab-runner CI, but it's a genuine bug in its own right: transient errors fetching optional optimization data (test timing/balancing) shouldn't be fatal to the whole run.

Suggested fix: treat any error from the timing fetch (not just ErrNoTimingDataAvailable) as non-fatal — warn and fall back to running without timing data, same as the "no data available" path already does.