Define safe environment transport for containerized stdio extensions

**What problem would this solve?**

Containerized stdio extensions need their configured environment forwarded without exposing values in the host process argument list, allowing extension variables to reconfigure the outer Docker client, or losing multiline and large values used for certificates and structured credentials.

Docker CLI transport has a three-way conflict:

- `--env KEY=value` places the value in host argv.
- `--env KEY` reads the target-named value from the Docker CLI process environment, where variables can change Docker, Go runtime, proxy, TLS, telemetry, or SSH behavior before the extension starts.
- `--env-file` keeps values out of argv and the Docker client environment, but its format is line-delimited and bounded, so it cannot preserve the currently accepted value domain.

The requested container is arbitrary, so Goose cannot assume that a shell or decoding helper exists inside it.

**What would a good outcome look like?**

Choose and document one supported contract for containerized stdio extension environments. The implementation should keep values out of host argv, prevent target variables from affecting host-side Docker behavior, preserve the agreed value domain, work across supported Docker contexts and platforms, and have direct regression coverage for confidentiality, lifecycle, and compatibility.

The key decision is: should container mode intentionally accept only bounded single-line environment values through a private env file, or should Goose add Docker Engine exec transport to preserve multiline and larger values?

**Possible approaches**

1. Use a private temporary `--env-file` for every target variable, fail closed on CR/LF and oversized entries, document the narrower container-mode contract, and recommend file/base64-based credential transport where needed.
2. Implement Docker Engine `ExecCreate`/`ExecStart` transport so environment strings are sent in the API body rather than host argv or process environment. This preserves multiline values but requires context/TLS/SSH/platform handling, HTTP upgrade and stream demultiplexing, lifecycle cleanup, and Podman compatibility verification.
3. Use another generic channel only if it works for arbitrary containers without consuming MCP stdio or requiring a target-side shell/helper.

Verification should cover ordinary and Docker/Go/SSH-control variable names, multiline and boundary-sized values, empty values, deterministic handling, private temporary-file lifecycle where applicable, exact argv contents, and both shared agent-loop entry paths.

**Additional context**

This decision surfaced while hardening containerized stdio startup. An allowlist of host-sensitive variable names is not sufficient because Docker and its runtime can add new environment controls over time.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

The issue is about designing a secure environment transport mechanism for containerized stdio extensions in Goose. Start by examining the existing container startup code and the Docker CLI integration. Look for how environment variables are currently passed (argv, host env, env-file). The decision point is between a restricted env-file contract and a more complex Docker Engine Exec API transport. Understanding the code paths for shared agent-loop entry and the verification requirements for confidentiality and compatibility is crucial. 'Done' means a documented contract and regression tests for the chosen approach.

索引モデルが issue の本文から書いたものです。