CI flakes on Docker image pull timeout: session-scoped redis_container fixture runs inside the global 10s pytest-timeout

[bijay-odyssey]

`pyproject.toml` sets a global `timeout = 10` (10 seconds) for the whole test session via pytest-timeout. The `redis_container` session-scoped fixture (`tests/conftest.py`) pulls a Redis Docker image as part of its setup — on a cold image cache or slow network, that pull alone can exceed 10s, and whichever test happens to trigger the fixture fails with `Failed: Timeout (>10.0s) from pytest-timeout` deep inside `docker/api/client.py` (blocked reading the image pull stream), cascading into 100+ unrelated test errors in the same run.

This isn't isolated to one PR/change — I hit it on a fix I opened, and confirmed the same trace on an unrelated PR's CI too:

• py3.14 job on Reject decode_responses=True in ArqRedis with a clear error #528: https://github.com/python-arq/arq/actions/runs/31895291991/job/95037575794
• multiple version jobs (py3.9/10/11/12/14) on a separate, unrelated PR: https://github.com/python-arq/arq/actions/runs/26793272680 and https://github.com/python-arq/arq/actions/runs/26793237271

Traceback shape is the same across all of them: `RedisContainer.enter` → `docker_client.images.pull` → blocked socket read → pytest-timeout fires.

Possible fixes:

• Scope a longer timeout specifically to the container-setup fixture (e.g. `@pytest.mark.timeout(...)` override on `redis_container`, or pre-pulling the image before the timeout window starts).
• Increase the global timeout, if 10s is just generally too tight given container-based tests.
• Pre-pull the Redis image as a separate CI step before `make test` runs, so the pull cost isn't inside any single test's timeout budget.

Happy to put up a PR for whichever approach maintainers prefer.