MySQL addon fails health check on first boot (15s timeout, cold init takes ~20s)

MySQL 8's Docker entrypoint runs a multi-phase initialization on first boot: mysqld --initialize to create the data directory, then a temporary server for setup SQL, then a restart as the real server. This sequence takes about 20 seconds in a containerized dev environment, but the sandbox port health check (controllers/sandbox/sandbox.go:1017) has a hardcoded 15-second timeout.

The health check is intentionally fail-hard (line 887-891: any error marks the sandbox DEAD, then pool crash-backoff retries). The problem is that 15s isn't enough for MySQL's cold init, so the first attempt always fails. The volume does persist across retries, so the second boot takes ~1 second (data dir already initialized), but crash-cooldown delays that retry significantly.

From the sandbox logs you can see MySQL actively initializing when it gets killed:

• 17:21:05 - MySQL Server Initialization - end (initialize phase done)
• 17:21:09 - Database files initialized, Starting temporary server
• 17:21:10 - InnoDB initialization has started (temp server phase)
• 17:21:24 - container killed with exit code 137 (15s health check fired)

Second boot with the persisted volume: InnoDB init takes 1 second, ready for connections at 17:21:27.

Found during local distributed runner testing but not specific to distributed mode. The blackbox MySQL addon tests pass in CI (faster hardware squeaks under 15s) but consistently fail locally.

Possible fixes: longer timeout for addon sandboxes, per-addon-type configurable timeout, or not treating the port check as fatal on first boot.