The new `_composite_write` method introduces two related bugs in its `_upload_chunk` coroutines run via `asyncio.gather`: (1) when `use_gzip=True`, `to_upload_body(chunk_data, use_gzip)` calls `gzip.compress(raw)` synchronously—a CPU-bound operation that can take seconds on a 64MB chunk—fully blocking the asyncio event loop before the first `await`, freezing all other async operations during every chunk's compression; (2) `asyncio.gather` without `return_exceptions=True` or `TaskGroup` does not 

The composite upload implementations in `compositeWrite` (JS) and `_composite_write` (Python sync/async) have no cleanup path on failure: if any chunk upload throws or the `/files/compose` call fails, all already-uploaded temp files at `/tmp/.e2b-upload-{uuid}-{n}` are permanently orphaned in the sandbox. The spec explicitly states source files are deleted only "after successful composition", so the server never removes them on error. Add a `try/finally` (or equivalent) block in each implementat