[BUG] AgentCore Harness: environmentVariables stored in resource config are not injected into microVM process env

## Describe the bug

`environmentVariables` set on `aws_bedrockagentcore_harness` (or via `CreateHarness` / `UpdateHarness` API directly) are stored and returned by `GetHarness` and `GetAgentRuntime`, but are **not injected into the microVM's process environment** — PID 1's `/proc/1/environ` and every subprocess spawned by the shell tool / skill scripts show them as absent.

Per [AWS docs — Environment variables](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-environment.html#harness-env-vars):

> Set environment variables that are **passed to the runtime container**. Environment variables are available to the agent and any custom container running in the session.

And [Custom environment (container images)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-environment.html#harness-custom-container):

> The harness overrides your container's `ENTRYPOINT` and `CMD` to keep it running as an environment. Your installed software, filesystem, and **environment variables are available to the agent**; your container's startup command is not executed.

Neither is true empirically today — the env vars are stored in the harness / runtime resource metadata but never reach the running container process.

## To Reproduce

1. Set any custom `environmentVariables` on a harness — via terraform, the SDK, or CLI. Example CLI:

```bash
aws bedrock-agentcore-control update-harness \
--harness-id \
--region \
--environment-variables '{"FOO": "bar"}'
```

2. Confirm the control plane accepted the write:

```bash
aws bedrock-agentcore-control get-harness \
--harness-id --region \
--query 'harness.environmentVariables' --output json
# → {"FOO": "bar"}

aws bedrock-agentcore-control get-agent-runtime \
--agent-runtime-id \
--region \
--query 'environmentVariables' --output json
# → {"FOO": "bar", "AWS_REGION": "...", "AWS_STAGE": "prod",
# "AWS_MEMORY_ARN": "...", "AWS_CUSTOMER_CONTAINER_URI": "...",
# "AWS_TRUNCATION_STRATEGY": "sliding_window",
# "AWS_TRUNCATION_MESSAGES_COUNT": "150"}
```

3. Invoke the harness with any prompt that triggers a shell tool call, and enumerate the container process env directly (not via the shell tool's own subprocess — read `/proc/1/environ` to bypass subprocess-env-reset concerns):

```
shell> cat /proc/1/environ | tr '\0' '\n' | sort
# → PATH=/usr/local/bin:...
# → LANG=C.UTF-8
# → GPG_KEY=...
# → PYTHON_VERSION=3.12.14
# → PYTHON_SHA256=...
# → HOSTNAME=localhost
# → HOME=/root
#
# NEITHER FOO nor any of the AWS_* system-injected vars appear.
```

`printenv FOO` from the shell tool returns exit code 1 and empty stdout. The pattern is identical for the AWS_* system vars — `printenv AWS_REGION` also returns nothing, even though `get-agent-runtime` shows AgentCore has populated it.

## Expected behavior

Per the linked docs, both:

- User-set `environmentVariables` (e.g. `FOO=bar`), AND
- AWS-injected system env vars (`AWS_REGION`, `AWS_STAGE`, `AWS_MEMORY_ARN`, `AWS_CUSTOMER_CONTAINER_URI`, `AWS_TRUNCATION_*`)

should appear in `/proc/1/environ` and in every subprocess spawned inside the microVM.

## Actual behavior

Only the base container image's own env vars — from Dockerfile `ENV` lines and Python base image defaults — are visible. Zero of the AgentCore-set `environmentVariables` reach the process, including the AWS_* system vars the runtime itself claims to inject. PID 1 is a bare `sh` from the Docker base image, not something wrapping / exporting the AgentCore-provided env.

## Interim workaround

Bake env vars directly into the container image as `ENV` lines. Docker ENV becomes part of the image and is inherited by the process regardless of AgentCore's runtime injection layer:

```Dockerfile
FROM public.ecr.aws/docker/library/python:3.12-slim
ENV FOO=bar
ENV AWS_REGION=ap-southeast-1
# ...
```

This confirms the container itself accepts env vars fine, so the issue is in AgentCore's runtime start / env-injection layer, not the container image or the terraform provider.

Trade-off: image becomes environment-specific (staging vs production must be separate images), which defeats the design intent of runtime-injected env vars — the whole point of the API's `environmentVariables` field is to let one image serve every environment.

## Environment

- Region: `ap-southeast-1`
- Model: `global.anthropic.claude-sonnet-4-6` (Bedrock, converse_stream)
- Runtime `networkMode`: `VPC`
- Custom container image: `python:3.12-slim` base, `linux/arm64`, `ENTRYPOINT`/`CMD` unset (per docs — AgentCore overrides them)
- Runtime version: (from `service.instance.id` in OTel resource — AgentCore-managed, no user control)

## Impact

Blocks the intended env-var-driven configuration pattern (per-env values for API tokens, table IDs, feature flags, etc.). Every env-var-consuming skill script — `boto3` clients reading `AWS_REGION`, framework code reading `AWS_STAGE`, application code reading `LARK_BASE_APP_TOKEN` / `LARK_APPROVAL_CODE` / etc. — falls back to hardcoded defaults or fails outright.

## Additional context

Repro is deterministic — happens on every new session against any harness that has `environmentVariables` set. Docker ENV workaround (baked at image build time) proves the container process accepts env vars; the missing layer is AgentCore's runtime start / injection. Even the *system-injected* `AWS_*` vars listed in `get-agent-runtime` don't reach PID 1, so this isn't a "user config not honored" edge case — it's a general failure of the injection step.

Related: `aws_bedrockagentcore_harness` terraform provider correctly wires the `environment_variables` field to the AWS API; the value round-trips through the control plane state cleanly. The gap is strictly service-side (runtime container start).

Aucun fichier du dépôt ni aucun test n’est identifié ; le rapport attribue le manque à la couche de démarrage du runtime et d’injection de l’environnement du service AgentCore. Reproduisez-le avec l’AWS CLI, puis inspectez /proc/1/environ et la sortie du sous-processus ; le travail est considéré comme terminé lorsque les variables utilisateur et les variables injectées par AWS apparaissent dans l’environnement de processus de la microVM, plutôt que de nécessiter des entrées ENV dans Dockerfile.

Rédigé par le modèle d'indexation à partir du texte de l'issue.