e2e: dataplane capture can spend its whole outer budget on one hung kubectl get, and truncation is silent #3642

Summary

hack/e2e-capture-dataplane.sh carries six kubectl get calls with no per-call bound (lines 261, 271, 387, 425, 427, 614 at 605030b), while every one of its 27 kubectl exec calls goes through a bounded wrapper and three of its other kubectl get calls carry an inline timeout 20 (lines 596, 635, 644). The script's own header comment (lines 242-246) is explicit that wall-clock is bounded only by the caller's envelope: 600s from the cozytest.sh EXIT trap, 300s from the Chainsaw global catch.

Why it matters

Against an apiserver that hangs rather than refuses (a runner whose kubeconfig points at a dead endpoint, an apiserver mid-crash), the very first unbounded call, kubectl get pods -A on line 261, consumes the entire envelope before any capture is written. From the Chainsaw catch the result is worse than empty: the capture is cut off by the outer timeout -k, and the script writes no note about being cut short, so a truncated capture is indistinguishable from a complete one that found nothing. Its sibling e2e-capture-previous-logs.sh already solves both halves: it self-caps its listing (PREVLOG_LIST_TIMEOUT=28, line 187) and logs "the read was cut off by ..." when a bound fires (line 381).

This is the same class as the collector-bounding work that recently landed for the report collector and the tenant cleanup waits; this script is the remaining member.

Fix shape

Give the six calls the same inline bound the script already uses elsewhere (timeout 20, with the existing grace pattern), sized so the sum of worst cases stays inside the 300s Chainsaw envelope, and emit a cut-off note in the sibling's discipline whenever a bound fires so a truncated capture identifies itself.