fix: bound the async image download to the same 5s as sync

[pucedoteth]

Problem

ImageResponse.image downloads the image when the API returns a URL rather than base64. The two transports disagree on how long that may take:

	call	effective timeout
sync/image.py:362	requests.get(..., timeout=5)	5s
aio/image.py:362	aiohttp.request("GET", ...)	300s

aiohttp.request with no timeout falls back to aiohttp's default, which I confirmed against the pinned version:

aiohttp 3.12.12
DEFAULT_TIMEOUT = ClientTimeout(total=300, connect=None, sock_read=None, sock_connect=30, ...)

So the same operation is bounded 60× more loosely on the async client than the sync one already decided was right. On a stalled CDN connection, await response.image blocks for five minutes — in an async program, usually while holding whatever task the caller expected to be short.

Fix

Both paths now read IMAGE_DOWNLOAD_TIMEOUT_SECONDS from the shared xai_sdk.image module instead of each carrying its own literal, so they cannot drift apart again. The sync behaviour is unchanged — it just stops hardcoding the number.

These are the only two outbound HTTP calls in the SDK (grep for requests./aiohttp. across src/xai_sdk returns exactly these two); everything else is gRPC, so the scope really is this pair.

Tests

One test per suite, asserting the timeout that actually reaches the transport:

• tests/sync/image_test.py::test_url_download_uses_the_shared_timeout
• tests/aio/image_test.py::test_url_download_uses_the_shared_timeout

With the two handlers reverted, the async one fails with KeyError: 'timeout' — no timeout was passed. The sync one passes either way, which is correct: the sync path was never the bug, and that test is there to keep it from becoming one.

Checks

All four from CONTRIBUTING, run locally:

check	result
uv run ruff format --check	122 files already formatted
uv run ruff check	All checks passed!
uv run pyright	0 errors, 0 warnings
uv run pytest -n auto	824 passed (822 before, +2 new)