bwrap sandbox does not mount /etc/hosts — breaks localhost DNS resolution in containers

## Problem

When the Claude Agent SDK (0.1.56, bundled CLI 2.1.92) runs inside a Docker container that routes outbound traffic through a proxy at `localhost:3128`, all Bash tool commands that call AWS services fail with DNS resolution errors.

The bwrap sandbox creates an isolated filesystem/network namespace but does not bind-mount `/etc/hosts` from the host. Without `/etc/hosts`, there is no mapping from `localhost` to `127.0.0.1`, so any process inside the sandbox that needs to resolve `localhost` fails.

## Error

```
socket.gaierror: [Errno -3] Temporary failure in name resolution
urllib3.exceptions.ProxyError: ('Unable to connect to proxy',
NameResolutionError("AWSHTTPConnection(host='localhost', port=3128):
Failed to resolve 'localhost'"))
botocore.exceptions.ProxyConnectionError:
Failed to connect to proxy URL: "http://localhost:3128"
```

## Environment

- **Claude Agent SDK**: 0.1.56
- **Bundled CLI**: 2.1.92
- **Container**: Docker (Debian bookworm-slim), running as non-root user (uid 1000)
- **Platform**: AWS Bedrock AgentCore runtime
- **Sandbox config**: `sandbox: { enabled: true, autoAllowBashIfSandboxed: true, enableWeakerNestedSandbox: true }`

## Reproduction

1. Run the SDK inside a Docker container where outbound traffic is proxied through `localhost:3128` (standard in AWS Bedrock AgentCore runtimes)
2. Enable the sandbox (`sandbox.enabled = true`)
3. Have the agent execute any Bash command that calls AWS via boto3 (e.g., `audit scorecard` which calls `boto3.client("rds-data")`)
4. boto3 tries to fetch IAM credentials from the container metadata endpoint via the proxy → DNS fails → all AWS calls fail

## Expected Behavior

The bwrap sandbox should bind-mount `/etc/hosts` from the host into the sandbox namespace so that `localhost` (and any other host-defined name mappings) resolve correctly inside sandboxed Bash commands.

## Workaround

We are currently disabling the sandbox entirely (`sandbox.enabled = false`) to restore pre-2.1.92 behavior where Bash commands run directly in the container. This works but sacrifices the sandbox security benefits.

## Context

- CLI 2.1.81 (bundled in SDK 0.1.50) did not use bwrap sandboxing for Bash commands — everything worked
- CLI 2.1.92 introduced bwrap sandboxing — this is when the issue appeared
- The bwrap init issue (`Can't mkdir /app/.claude: Permission denied`) was separately resolved by setting `cwd` and `HOME` explicitly — this issue is specifically about the network namespace missing `/etc/hosts`