Update dependency e2b

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
e2b (source)	2.16.0 → 2.19.0
e2b (source)	2.15.0 → 2.18.0

---

Release Notes

e2b-dev/e2b (e2b)

v2.18.0

Compare Source

Minor Changes

• 6d7e72e: added volumes support to the SDKs

v2.17.0

Compare Source

Minor Changes

• f7f1f29: Update SDK READMEs

e2b-dev/e2b (e2b)

v2.18.0

Compare Source

Minor Changes

• 6d7e72e: added volumes support to the SDKs

v2.17.0

Compare Source

Minor Changes

• f7f1f29: Update SDK READMEs

v2.16.0

Compare Source

Minor Changes

• 7c8d298: adds network configs and lifecycle handling to info responses

Patch Changes

• 1c55083: Fix missing instance config propagation in Sandbox pause/connect and add regression tests for config forwarding + overrides.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[JiwaniZakir]

The Python SDK (packages/python-sdk/poetry.lock and template/poetry.lock) locks to e2b==2.19.0 while the JS SDK (pnpm-lock.yaml) resolves to e2b@2.18.0 — the two SDKs are now on different minor versions of the same core dependency. If the e2b API surface changed between 2.18.0 and 2.19.0, this could introduce subtle behavioral inconsistencies between the Python and JS codepaths that would be difficult to diagnose. It's worth either aligning both to 2.19.0 or documenting why the version skew is intentional.

Additionally, the specifier field in pnpm-lock.yaml still reads ^2.8.4 for e2b — this is a very wide range that technically allows resolving anywhere from 2.8.4 to <3.0.0. Since the project is now intentionally running on 2.18.0, it would be safer to tighten the specifier in package.json to something like ^2.18.0 so future installs don't silently resolve to an untested older version in a fresh environment.