fix(python): keep timeout=0 on sandbox create and connect

[claxman]

Fixes #1840

Sandbox.create(timeout=0) and Sandbox.connect(..., timeout=0) used timeout or default, so 0 became 300 seconds. JS create uses timeoutMs ?? default and keeps 0. Fork already used if timeout is not None.

Same if timeout is not None default in sync and async _create and _cls_connect. I did not reject timeout <= 0. JS sends 0.

Testing (no live API):

cd packages/python-sdk && .venv/bin/python -m pytest tests/shared/sandbox/test_timeout.py -q --tb=short

6 passed. Restoring the four or defaults makes the four timeout=0 cases fail with posted timeout 300 instead of 0.

Sandbox.create(timeout=0, api_key=...)
# POST body timeout is 0, not 300

[changeset-bot]

🦋 Changeset detected

Latest commit: 0a0e268

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@e2b/python-sdk	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[devin-ai-integration]

TASTE.md review: checked T-1/T-2 (JS↔sync↔async parity — the is not None default now matches JS timeoutMs ?? default and the existing fork handling, applied identically in sandbox_sync and sandbox_async), T-44/T-47 (sandbox-lifetime clock, default via the named default_sandbox_timeout constant, no magic numbers), T-52 (no client-side rejection of timeout <= 0 — left to the backend). 0 violations; the change complies with TASTE.md.

[claxman]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[mishushakov]

I believe this is on purpose, keep in mind also that we will be dropping all the SDK defaults from the SDK in favor of backend-defined values:
#1749

[claxman]

You're right. timeout or default treating 0 as unset is the current Python idiom, and #1749 is dropping those SDK defaults. Closing this.