[Bug]: Kubernetes sandbox command timeout does not bound stalled response bodies #3883

Describe the bug

In the Kubernetes sandbox client, CommandExecutor.run(command, timeout) accepts a timeout but does not pass it to the HTTP connector. SandboxConnector uses blocking HttpClient.send() with BodyHandlers.ofString() / ofByteArray(). A peer can return response headers and then leave the response body unfinished, keeping the caller blocked beyond the command timeout. The request timeout alone does not bound completion of the response body on the tested JDK.

To Reproduce

1. Point a Kubernetes sandbox client at a local HTTP fixture.
2. For /execute, send HTTP 200 headers and keep the body open without completing it (for example, HttpServer.sendResponseHeaders(200, 0) followed by a latch).
3. Call sandbox.commands().run("echo hello", Duration.ofSeconds(1)).
4. Observe that the call can remain blocked beyond the supplied timeout while the body remains open.

The same connector behavior affects file downloads. A local HTTP-server regression test is included in the accompanying fix; it requires no Kubernetes cluster or credentials.

Expected behavior

Bound the complete HTTP exchange, including response-body completion, and surface a recognizable timeout to the client/Harness. Command execution should remain a single attempt to avoid replaying a potentially executed command. Existing public method signatures should remain compatible.

Error messages

No timeout is necessarily raised while the response body remains unfinished.

Environment

• AgentScope Java: 2.1.0-SNAPSHOT, inspected at e190a8d1b855312af5f349334ec14c6ea1013d4f; proposed fix based on 6ee80445713ccc4878ddfd41620e1de544d3ea8c.
• Java: 21.0.12; project target: Java 17.
• OS: Windows.

Additional context

This report concerns the client's HTTP wait. Cancelling an HTTP exchange does not guarantee termination of the remote command; server-side process limits are a separate concern. Connection discovery and Kubernetes metadata lookups also retain their existing timeout behavior. This is distinct from E2B process termination in #2976 and the already-fixed redirect handling in #2748.