[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).

No repository file or test is identified; the report attributes the gap to the AgentCore service-side runtime start and environment-injection layer. Reproduce with the AWS CLI, then inspect /proc/1/environ and subprocess output; done means user and AWS-injected variables appear in the microVM process environment rather than requiring Dockerfile ENV entries.

Written by the indexing model from the issue text.