Do not pull the tiny image for gateway detection when checks are disabled

[Baqirrizvidev]

Fixes #11241

What broke

With TESTCONTAINERS_CHECKS_DISABLE=true, the tiny image (alpine:3.17) is still pulled in some environments, even though the docs state the tiny image is "always required (unless startup checks are disabled)".

The unguarded path is default gateway detection. When the tests themselves run inside a container (IN_A_CONTAINER, e.g. a containerized Jenkins agent) and inspecting the bridge network yields no gateway, DockerClientProviderStrategy.resolveDockerHostIpAddress falls back to DockerClientConfigUtils.getDefaultGateway(), which runs ip route inside a tiny-image container — pulling alpine:3.17 regardless of checks.disable.

This matches the log in #11241 exactly: runInsideDocker first touches ResourceReaper.instance() (printing the "Ryuk has been disabled" warning) and then pulls the image, which is the reported warning → pull sequence. In the reporter's CI the registry cannot serve alpine:3.17, so the pull fails — and because that failure propagates out of the lazy initializer, host IP resolution (and the whole test run) crashes.

The fix

In DockerClientConfigUtils:

1. Skip container-based gateway detection when checks.disable=true, falling back to localhost (users who need a specific address in such setups can still set TESTCONTAINERS_HOST_OVERRIDE). This honors the documented contract that the tiny image is not required when checks are disabled.
2. Catch failures of the detection container itself (e.g. the image pull failing against a restricted registry) and fall back gracefully instead of crashing host IP resolution.

Added a unit test asserting that gateway detection does not touch Docker when checks are disabled.

🤖 Generated with Claude Code