Fetch pod logs with the caller's kubectl, and reject flag-like arguments

[erictt]

Fixes shop/issues#84857 and shop/issues#84856, and bumps the version to 3.9.2.

Pod logs ignored the task's kubeconfig (shop/issues#84857)

ContainerLogs built its own Kubectl from a TaskConfig without a kubeconfig, so kubectl logs fell back to ENV['KUBECONFIG']. Every other call in the task used the explicit kubeconfig:. In a process that deploys with a per-task kubeconfig but has a different ambient one, logs could be read from the wrong cluster.

Both log paths already hold a task-scoped kubectl: sync_debug_info(kubectl) and Pod#sync(cache) through ResourceCache. So ContainerLogs/RemoteLogs#sync and fetch_debug_logs now take the caller's kubectl, the same way fetch_events(kubectl) does, and the extra client is gone. No constructor signatures change.

Arguments parsed by kubectl as flags (shop/issues#84856)

namespace, context and kind were passed to kubectl as bare positional arguments, so a value like --server=http://attacker.example was parsed as a flag. Each is now validated before it's used:

• namespace: must be a DNS-1123 label, which Kubernetes requires anyway.
• context: must not start with -. Context names vary too much (gke_…, arn:aws:eks:…) for a stricter format.
• kind: must start with a letter. Hyphens stay allowed because Cron-Tab is a valid CRD kind.

I audited every other dynamic argument to Kubectl#run. The rest are either krane-generated (tempfile paths, discovery API paths) or passed as a single --flag=value argument.

Flaky test_jobs_can_fail

It failed in each of the last 4 CI runs. With backoffLimit: 1, the Job could fail on its first pod crash before Kubernetes recorded DeadlineExceeded. The test now uses the default backoffLimit, and it asserts on krane's DeadlineExceeded (…) failure message instead of the asynchronous event.

Testing

8 new unit tests, each confirmed to fail without the fix. CI passes 97/97, including test_jobs_can_fail in all 24 integration jobs.