feat: add transfer_timeout option for large uploads

[jpnurmi]

Add transfer_timeout as a dedicated option for SDK-managed HTTP transports. The proposed default is 0 (no transfer timeout), which was the previous default for curl.

This matters most for large uploads: without server-side chunked/resumable upload support, a long/hanging transfer can occupy the single-threaded transport pipeline for a long time.

Transfer timeouts were previously inconsistent across transports: curl had no total transfer timeout, while WinHTTP was capped by the 30s OS-default send/receive timeout that is too low for large uploads. This makes the behavior explicit and configurable without overloading shutdown_timeout, which only controls shutdown waits. Large uploads can also happen while retrying cached envelopes on restart, so the timeout needs to apply to HTTP transfer behavior rather than shutdown waiting.

Crashpad's own crash report upload does not support this option, but it does have a hardcoded 60s limit:

• https://github.com/getsentry/crashpad/blob/ff141a8c0cc852f9c3d42e13bd9ada551351bc21/client/settings.h#L52-L58
• https://github.com/getsentry/crashpad/blob/ff141a8c0cc852f9c3d42e13bd9ada551351bc21/handler/crash_report_upload_thread.cc#L348-L349

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 1b72b8a

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit dc70579. Configure here.}