Add eksctl proxy command

[gtsiolis]

Adds lstk eksctl, a proxy that runs the installed eksctl binary against the running LocalStack AWS emulator. It replaces the manual endpoint exports from LocalStack's eksctl integration guide with:

lstk eksctl create cluster --nodes 1

The proxy:

• requires eksctl 0.181.0 or newer and fails closed when its version cannot be determined or parsed
• resolves the running AWS emulator and injects the CloudFormation, EC2, EKS, ELB, ELBv2, IAM, and STS endpoint variables plus AWS_ENDPOINT_URL
• honors an explicit AWS_ENDPOINT_URL, while removing inherited service-specific endpoint overrides and forcing configured endpoints to remain enabled so requests cannot fall through to real AWS
• strips inherited AWS profiles and session tokens, defaults credentials only when missing or empty, and derives a consistent AWS_REGION/AWS_DEFAULT_REGION pair from either user-provided region
• forwards arguments, stdio, exit codes, and signals through the same process runner used by the other wrapped tools
• lets version, info, completion, and genuine help requests run without Docker, a running emulator, or the version gate
• supports LSTK_EKSCTL_CMD for selecting a different eksctl binary

The command is registered in the Tools group and documented in the README. Unit and integration coverage exercises version gating, help/offline classification, environment isolation, endpoint and region precedence, emulator/runtime gates, argument and JSON flag forwarding, exit codes, and the Docker-backed command path.

eksctl support in LocalStack is experimental, and EKS requires the Ultimate plan.

Closes PRO-367

[nik-localstack]

Nice!
I tested it locally with a few simple flows and it works nice.
I cannot comment a lot on the code but in general it looks good to me.

[peter-smith-phd]

I'm happy with the general idea of adding eksctl, although I do want to see a strategy on how to handle service-specific tools like this. EKS is just one of 100+ services we support, so I don't feel it deserves a top-level command in lstk.

Before I'd be comfortable with this, I'd like to see our lstk design approach for handling service-specific tooling.