feat: ContainerCodeExecutor should support input_files and output_files

## Summary

`ContainerCodeExecutor` currently ignores `CodeExecutionInput.input_files` and always returns an empty `output_files` list. This makes it impossible to pass files into the container or retrieve generated files from it.

## Current Behavior

In `container_code_executor.py`, `execute_code()`:

```python
exec_result = self._container.exec_run(
['python3', '-c', code_execution_input.code],
demux=True,
)
return CodeExecutionResult(
stdout=output,
stderr=error,
output_files=[], # Always empty
)
```

- `code_execution_input.input_files` is **completely ignored**
- `output_files` is **always an empty list**
- No Docker volume mounts are configured
- `optimize_data_file` is forced to `False` (frozen)

## Expected Behavior

`ContainerCodeExecutor` should support file I/O through the existing `File` / `CodeExecutionInput` / `CodeExecutionResult` data structures, which already support binary content (`content: str | bytes`).

### Suggested approach

1. **Input files**: Use `container.put_archive()` to copy `input_files` into the container (e.g., to `/tmp/inputs/`) before code execution
2. **Output files**: Use `container.get_archive()` to retrieve files from a designated output directory (e.g., `/tmp/outputs/`) after code execution
3. Alternatively, support a `volumes` parameter for Docker bind mounts

## Use Case

We use an LLM agent system where a supervisor agent downloads files (e.g., Excel, CSV) to `/tmp/` and needs to pass them to a code execution agent for processing (e.g., data transformation with openpyxl/pandas).

- `BuiltInCodeExecutor` runs on the Gemini server, so it **cannot access local files**
- `UnsafeLocalCodeExecutor` can access local files but is **not safe for production** (unrestricted `exec()` with access to credentials, env vars, etc.)
- `ContainerCodeExecutor` would be the ideal middle ground — **isolated execution with file access** — but file I/O is not implemented

## Impact

Without file I/O support, `ContainerCodeExecutor` is limited to pure computation tasks (math, data generation). File processing workflows must either:
- Use `BuiltInCodeExecutor` (no local file access) and pass all data through LLM context (slow for large data)
- Use `UnsafeLocalCodeExecutor` (security risk in production)

## Environment

- ADK version: google-cloud-aiplatform[adk] 1.100.0
- Python: 3.12+