[sandbox-e2b] exec timeout is unreliable: readTimeout preempts callTimeout, no server-side kill, cancellation misreported

## Problem

`E2bEnvdProcessClient.runShellCapture()` timeout handling (`agentscope-extensions/agentscope-extensions-sandbox/agentscope-extensions-sandbox-e2b/src/main/java/io/agentscope/extensions/sandbox/e2b/E2bEnvdProcessClient.java`) has three defects:

1. **Premature false timeout.** The per-call client only sets `callTimeout(timeoutSeconds)` and inherits the base `readTimeout`:

```java
http.newBuilder().callTimeout(timeoutSeconds, TimeUnit.SECONDS).build()
```

If base `readTimeout < timeout` (e.g. custom client `readTimeout=1s`, exec `timeout=3s`), the idle `readTimeout` fires first. The resulting `InterruptedIOException` is caught and wrapped as `ExecTimeoutException("timed out after 3s")`, but only ~1s elapsed.

2. **Timed-out remote process is left running.** `buildEnvdRequest()` sends no `Connect-Timeout-Ms` header, so timeout only disconnects the client HTTP stream. The sandbox process (e.g. `sleep 1000`) keeps running — leak / unexpected billing.

3. **External cancellation misreported as timeout.** `catch (InterruptedIOException)` unconditionally throws `ExecTimeoutException`, even when the thread was interrupted by outer cancellation. The interrupt bit is swallowed.

## Repro

- Base client `readTimeout=1s`, `runShell(..., timeoutSeconds=3)` against a hanging envd stream (`NO_RESPONSE`).
- Expected: `ExecTimeoutException` after ~3s.
- Actual: `ExecTimeoutException` after ~1s with message claiming 3s.

## Expected

- `readTimeout` for the call must stay above `callTimeout` so total-duration semantics wins.
- Send `Connect-Timeout-Ms` when `timeoutSeconds > 0` so envd kills the process server-side.
- If `Thread.currentThread().isInterrupted()`, restore the bit and rethrow instead of wrapping as timeout.