Avoid unconditional MCP gateway bootstrap for workspaces that do not use MCP

## Problem

`SandboxedWorkspaceBase.initialize()` unconditionally initializes the in-sandbox MCP gateway:

```python
await self._provision_backend()
await self._ensure_workspace_layout()
await self._setup_mcp_gateway()
await self._setup_skills()
```

This happens even when:

- `default_mcps` is empty;
- the persisted `.mcp` file is empty;
- the application only uses built-in Bash/file tools and Skills.

All workspace implementations derived from `SandboxedWorkspaceBase` are affected, including OpenSandbox, E2B, Daytona, Kubernetes, and Docker. Docker usually pays the installation cost at image-build time, but it still launches and health-checks the gateway on every initialization.

For a fresh remote sandbox, the OpenSandbox/E2B/Daytona/Kubernetes paths may need to:

1. install system packages such as `ripgrep`;
2. download and install `uv`;
3. create a gateway virtual environment;
4. install `mcp`, `fastapi`, `uvicorn`, and `agentscope`;
5. upload, launch, and health-check `_mcp_gateway_app.py`.

This can add minutes to cold-start latency and introduces package-index and external-network dependencies before a workspace can be used, even though Bash, file operations, and Skills do not require the MCP gateway.

## Minimal reproduction

```python
workspace = OpenSandboxWorkspace(
image="python:3.11-slim",
domain=domain,
api_key=api_key,
skill_paths=["./skills/pdf"],
)

await workspace.initialize()
```

No MCP server is configured, but initialization still bootstraps and starts the MCP gateway.

The same behavior follows from the shared base class for E2B, Daytona, and Kubernetes workspaces.

## Expected behavior

A sandboxed workspace with no configured or persisted MCP servers should become usable without installing or starting the MCP gateway. Built-in tools and Skills should continue to work through the workspace backend.

The gateway should be initialized when it is actually needed.

## Suggested design

One possible approach is lazy initialization:

- During `initialize()`, inspect `default_mcps` and the persisted `.mcp` configuration.
- If both are empty, skip gateway bootstrap and launch.
- Add an internal `_ensure_mcp_gateway()` path that bootstraps/starts the gateway when `add_mcp()` or another MCP-dependent operation is first used.
- If persisted MCP configuration exists when a workspace is resumed, start the gateway eagerly and restore those MCPs.
- Make `list_mcps()` return an empty list without requiring a running gateway when no MCP has been configured.

Alternatively, expose an explicit mode such as `mcp_gateway="auto" | "eager" | "disabled"`, with a backward-compatible default.

## Acceptance criteria

- A new sandboxed workspace with no MCP configuration does not install or launch the MCP gateway.
- Bash, Read, Write, Edit, Glob, Grep, and Skills still work without the gateway.
- Adding an MCP lazily starts the gateway and preserves current MCP behavior.
- A resumed workspace with persisted MCP configuration restores its gateway and MCP servers.
- Existing eager behavior remains available for users who rely on it.
- The behavior is covered consistently for OpenSandbox, E2B, Daytona, Kubernetes, and Docker workspaces.

## Environment

Observed with AgentScope `2.0.4.post1` while using `OpenSandboxWorkspace`, but the unconditional call is in `SandboxedWorkspaceBase` and therefore applies to the other sandboxed workspace implementations as well.