fix(uploads): reuse configured http client for storage uploads

[AbdelStark]

Summary

Route the second-stage storage upload in uploads.create_ephemeral() through the configured SDK client instead of instantiating a fresh httpx client.

Why

The SDK documents support for custom http_client, proxies, transports, and DefaultAioHttpClient(), but the actual blob upload path bypassed that configuration. That broke the contract on the highest-bandwidth upload path.

Root Cause

create_ephemeral() used the SDK client for the control-plane /v1/uploads call, then created a brand-new httpx.Client or httpx.AsyncClient for the storage POST. That dropped the caller's configured transport, proxy, and pooling behavior.

Changes

• add shared sync and async helpers in the base client to send explicit multipart requests through the configured underlying client
• update sync and async upload resources to reuse the configured client for the storage POST
• keep SDK auth headers off the storage request while preserving upload-specific timeout handling
• add sync and async regression tests covering transport reuse and header isolation

Impact

Uploads now honor custom transports, proxy settings, and the aiohttp backend on the storage POST, while reusing connection pooling for repeated media uploads.

Validation

• python3 -m py_compile src/runwayml/_base_client.py src/runwayml/resources/uploads.py tests/api_resources/test_uploads.py
• .venv310/bin/python -m pytest tests/api_resources/test_uploads.py -o addopts='--tb=short' (26 passed)