Fix k8s execute command argv handling

[Devamparikh]

Why

While testing Kubernetes exec through kagent from a Teams bot, I ran into a confusing failure mode: asking the agent to run uname -a inside a pod reached kagent-tools, but Kubernetes tried to execute a binary literally named uname -a.

That made the whole A2A/MCP path look broken at first, even though routing, auth, approvals, and the target pod were all working. A single-word uname succeeded, which narrowed the issue down to how k8s_execute_command builds the kubectl exec argv.

This PR fixes that sharp edge so simple exec commands behave the way users and agents naturally expect.

What changed

• Split Kubernetes exec commands into argv tokens instead of passing multi-word commands as one executable.
• Added an explicit args array for flags/arguments, so callers can send structured input such as command: "uname", args: ["-a"].
• Kept backward compatibility for simple whitespace-separated command strings such as command: "uname -a".
• Honored the existing container input by passing -c <container> to kubectl exec.
• Validated each argv token and the container name before execution.

Fixes #59.

Testing

• go test ./pkg/k8s
• Built a validation image from this branch and deployed it temporarily to a COM EKS cluster on an amd64 node.
• Verified direct MCP k8s_execute_command succeeds with command: "uname", args: ["-a"], container: "twistlock-defender".
• Verified backward-compatible direct MCP call succeeds with command: "uname -a".
• Live kagent-tools logs showed kubectl invoked as separate argv pieces: exec ... -c twistlock-defender -- uname -a.

[Devamparikh]

Hi @EItanya @dimetron, I noticed CODEOWNERS routes this repo to you, so I wanted to gently flag this PR for review.

I hit this while validating kagent exec through Teams/A2A: the request reached kagent-tools correctly, but kubectl exec treated uname -a as one executable. This PR keeps the existing simple command-string behavior working while adding a structured args path and honoring container. I also validated it against a live EKS test cluster via direct MCP before opening the PR. Thanks!