[FEATURE] Add a limit parameter to k8s_get_resources to bound context growth

Start at the k8s_get_resources wrapper around kubectl get and trace how all_namespaces and each output format are handled. Resolve whether the default remains unlimited or becomes finite, then ensure the limit and truncation totals are represented correctly, with JSON remaining valid and YAML handled as specified.

Problem

k8s_get_resources wraps kubectl get and has no way to bound how much it returns. On a large cluster an agent that calls it with all_namespaces=true gets every row of every namespace in a single tool result, which goes straight into the model's context.

In our production estate this is the single largest source of context growth. An agent turn that issued a handful of cluster-wide k8s_get_resources calls reached several million input tokens and exhausted the model's context window, which ends the turn with an error rather than a large-but-usable answer. The failure is also expensive, because the oversized listing is paid for on every subsequent turn that carries the history.

Prompt guidance alone has not been enough for us. Telling the agent to query narrowly reduces how often it happens, but the tool still permits an unbounded listing, so a single unlucky call undoes it. The parameters today are resource_type, resource_name, namespace, all_namespaces and output — none of them cap result size.

Proposal

Add an optional limit parameter to k8s_get_resources that caps the number of resources returned, with limit=0 returning everything.

Two details matter for it to be safe:

• The truncated result should say it was truncated and give the totals. A silently shortened listing reads as complete, so the model draws conclusions from partial data — which is worse than the original problem.
• Truncation has to respect the output format. Slicing lines out of a -o json document would return an invalid one, so JSON should be cut at its items array and YAML left alone.

Whether the default should be a finite cap or unlimited is the main open question. A finite default is what actually protects agents that do not know to pass the parameter, but it changes behaviour for existing callers. Happy to follow whichever the maintainers prefer.

I have a change ready and will open a PR against this issue.