Helmfile use_eks: aws eks update-kubeconfig subprocess does not receive Atmos auth env (--identity)

## Summary

When `components.helmfile.use_eks` is `true`, Atmos runs `aws eks update-kubeconfig` before Helmfile. That subprocess does not receive the sanitized Atmos-managed AWS environment (`AWS_SHARED_CREDENTIALS_FILE`, `AWS_CONFIG_FILE`, `AWS_PROFILE`, etc.) that is produced by the identity auth flow. As a result, `--identity` works for the Helmfile invocation (which uses `WithEnvironment(info.SanitizedEnv)`) but not for the kubeconfig download step.

## Expected behavior

The AWS CLI used for `aws eks update-kubeconfig` should use the same credentials as the rest of the command when `--identity` (or any Atmos auth that populates `SanitizedEnv` / `ComponentEnvSection`) is in effect.

## Actual behavior

`ExecuteShellCommand` for the AWS CLI is called with only toolchain env (`tenv.EnvVars()`) and no `WithEnvironment(info.SanitizedEnv)`. The child process falls back to `os.Environ()`, which does not include Atmos-prepared credential file paths unless the user happens to have compatible ambient credentials.

Additionally, `ComponentEnvSection` is merged into `ComponentEnvList` **after** the EKS block in `ExecuteHelmfile`, so auth-derived vars are not even on the list at the time `update-kubeconfig` runs.

## References

- `internal/exec/helmfile.go`: `aws eks update-kubeconfig` `ExecuteShellCommand` (env: `tenv.EnvVars()` only).
- Same file: final Helmfile `ExecuteShellCommand` uses `WithEnvironment(info.SanitizedEnv)`.
- `pkg/helmfile/auth.go`: `--identity` sets `UseIdentityAuth` and does not pass `--profile` to AWS CLI, so the CLI depends entirely on env/default chain for that step.

## Related

- `atmos aws eks update-kubeconfig` (`internal/exec/aws_eks_update_kubeconfig.go`) also shells out with `tenv.EnvVars()` only; consider aligning both code paths when fixing.

## Suggested direction

- Pass `WithEnvironment(info.SanitizedEnv)` (when non-nil) to the `aws eks update-kubeconfig` `ExecuteShellCommand`, and/or merge auth/component env into that subprocess in the same order as Helmfile.
- Add a test that asserts the AWS subprocess receives Atmos credential env when using identity (e.g. contract on env passed to `ExecuteShellCommand` or integration with a fake aws binary).

---

_Reported behavior observed at least on v1.212.0; issue reproduced by code inspection on current main._