Scope network-faults job to only run its own test

What does this MR do?

Adds a -run filter to the integration test (docker, network-faults) job so it only executes TestDockerCommandPullRetriesTransientRegistryFailure, instead of the entire executors/docker integration suite.

Why was this MR needed?

The job ran go test -tags integration,network_faults ./executors/docker with no -run filter. Go build tags are additive: a file constrained to just //go:build integration is still compiled and its tests still execute even when network_faults is additionally passed, since its own constraint is still satisfied. Confirmed locally:

$ go test -tags integration,network_faults -v ./executors/docker | grep -c '^=== RUN'
80
$ go test -tags integration,network_faults -run '^TestDockerCommandPullRetriesTransientRegistryFailure$' -v ./executors/docker | grep '^=== RUN'
=== RUN   TestDockerCommandPullRetriesTransientRegistryFailure

The other ~76 unrelated integration tests already consume close to the full 15-minute job timeout on their own (they're the same tests the main integration test job runs). TestDockerCommandPullRetriesTransientRegistryFailure is inherently one of the slower/later tests (it has its own ~3-13s of built-in waiting for retry backoff), so it was consistently the one still === RUN-ning when the whole-package timeout fired - reproducing in 12 of the last 14 runs of this job, across unrelated MRs and main itself.

This is a CI configuration bug, not a bug in the pull-retry logic (executors/docker/internal/pull/manager.go) or in the test's own assertions - both are correct as-is.

What's the best way to test this MR?

No Go code changed. Verified via glab ci lint (passes) and the local -run comparison above. Once merged, the job's next few real runs should complete in well under a minute instead of hitting the 15m timeout - worth checking https://gitlab.com/gitlab-org/gitlab-runner/-/pipelines after merge.

What are the relevant issue numbers?

Closes #39624 (closed)