Allow passing envs in POST /sandboxes/{id}/connect

⏺ Is your feature request related to a problem? Please describe.
Cannot pass new env variables when resuming a sandbox.

Sandboxes are often reused across long-lived sessions. Secrets injected at creation time (e.g. OAuth tokens, GitHub App installation
tokens, short-lived cloud credentials) expire well within the sandbox's lifetime — GitHub installation tokens, for example, expire
after 1 hour. Once expired, any process inside the sandbox that relies on $GITHUB_TOKEN (git pull/push, API calls, etc.) fails with
401.

Today the only workaround is to pass the refreshed secret as a command argument on every exec, which leaks it into process lists,
shell history, and logs. There's no way to update the sandbox's env after creation.

Describe the solution you'd like
Extend POST /sandboxes/{sandboxID}/connect to accept an envs field in the request body. Values would be merged into the sandbox's
env and applied to processes started after the resume.

curl --request POST
--url https://api.e2b.app/sandboxes/{sandboxID}/connect
--header 'Content-Type: application/json'
--header 'X-API-Key: '
--data '{
"timeout": 1,
"envs": {
"GITHUB_TOKEN": "ghs_..."
}
}'

This mirrors the envs field already supported on sandbox creation, and would let callers rotate short-lived secrets without leaking
them through command arguments.

Start by locating the POST /sandboxes/{sandboxID}/connect handler and the existing sandbox-creation path that accepts envs. Trace how environment values are stored and applied when a sandbox resumes, then add coverage for merging envs and making them available to processes started after reconnect.