Nightly db2 testcontainers job intermittently times out waiting for "Setup has completed"

SYMPTOM

The nightly Testcontainers CI job intermittently fails its testcontainers (db2, 25) leg with a TimeoutError from the engine fixture in tests/testcontainers/db_engine_specs/test_db2.py. First failing run: https://github.com/apache/superset/actions/runs/35185304121/job/105086001403 (commit 4c77b0b924a9bd770110915eacd68f5619e8241d).

ROOT CAUSE

with Db2Container() as container: calls testcontainers-python's Db2Container._connect (community/db2/__init__.py:54-56), which calls wait_for_logs(self, predicate="Setup has completed") with no explicit timeout — defaulting to the pinned testcontainers==4.15.0 library's global 120s wait (core/config.py:103-104,160-161). Db2's first-boot init is documented as notably slow (including in this workflow's own compute-matrix comment) and can exceed 120s even though the job has a 25-minute budget with ~21 minutes unused.

FIX

PR incoming: add an explicit .waiting_for(LogMessageWaitStrategy("Setup has completed").with_startup_timeout(900)) to Db2Container() in test_db2.py's engine fixture, matching the idiom already used by sibling fixtures (test_databend.py, test_oceanbase.py) in the same suite. No production code touched.

EVIDENCE

• Real CI log shows the container status was "running", mid-CREATE DATABASE, not hung, when the 120s wait fired.
• 1 failure in the last 8 retained nightly runs (2026-09-10 through 2026-09-17).
• Passing runs' session totals range 88-153s against the fixed 120s cap on this one phase — a margin defect, not a broken image or wrong predicate.