agentlab pods: the lab's pods across namespaces through the embedded client, kubectl get pods -A shaped, with a namespace filter

[teemow]

Part of #119.

Problem

Since #115 the binary needs no kubectl — but looking at pods still does: KUBECONFIG=state/kubeconfig kubectl get pods -A. Someone without kubectl cannot see why a component is Pending, and the boot summary's own hints (Check 'kubectl -n agent-platform get pods' in platform.go) point at a tool they may not have.

Proposed solution

agentlab pods [-n <namespace>] lists the lab's pods through the embedded client (internal/lab/kube.go, the typed clientset bound to state/kubeconfig) in the shape people know from kubectl get pods -A: NAMESPACE, NAME, READY (ready/total containers), STATUS (kubectl's verdict: a container's waiting reason such as ImagePullBackOff or CrashLoopBackOff when there is one, Completed, Terminating with a deletion timestamp, else the phase — podStateSummary is close and the wording can be shared), RESTARTS, AGE. Sorted by namespace then name; every namespace by default, -n narrows; -w/--watch re-lists on change (should-have). With the cluster not running: a refusal saying so and pointing at agentlab up, not a stack of client-go errors.

The hints in platform.go and in the docs that say kubectl -n … get pods point at agentlab pods instead; KUBECONFIG=state/kubeconfig kubectl … stays documented as the deeper look.

Acceptance criteria

• On a running lab agentlab pods lists every pod of every namespace in that shape; -n agent-platform only that namespace; a Pending pod shows its reason in STATUS.
• With the cluster down: the refusal, no client-go stack.
• Unit tests on the client-go fakes for the READY/STATUS/RESTARTS/AGE columns: running, waiting reason, terminated, terminating, init containers.
• The kubectl … get pods hints in platform.go and the docs point at agentlab pods.