fix(ci): bound kubectl/curl in e2e-seal-check.sh + helm-ci.yaml (backend#1497)

[aptracebloc]

Fixes the two Bugbot findings in tracebloc/backend#1497 (from the client#571 prod promotion) — unbounded external calls in CI that can hang a job to the GitHub Actions cap with no useful failure, the same class as the image-refresh fix (#572).

Changes

• scripts/tests/e2e-seal-check.sh — --request-timeout=10s on the point-in-time kubectl API calls (get ×2, run, logs ×2, delete, describe) so a wedged API server fails the seal-check fast.
  • kubectl wait (L57) left as-is on purpose: it's already bounded by --timeout=180s (a client-side deadline that fires even against a wedged server), and adding --request-timeout to its underlying watch would truncate the watch and risk flakes. Flagging since the ticket listed wait — happy to add it too if you'd rather, but --timeout already covers the hang.
• .github/workflows/helm-ci.yaml — --connect-timeout 15 --max-time 120 on the pinned kubeconform download so a stalled endpoint fails the template matrix instead of hanging. -f / --retry behaviour unchanged; the tarball is small so 120s is generous.

Notes

• Values mirror the repo's existing bounds (--request-timeout=5s/10s in install-client-helm.sh / diagnose.sh / storage-assertions-check.yaml; --connect-timeout/--max-time in install.sh / setup-linux.sh).
• No R8 manifest bump — neither file is in scripts/manifest.sha256 (a test script + a workflow).
• Validated locally: bash -n on the script, YAML parse on the workflow.

Ref tracebloc/backend#1497 · parent #1405 · siblings #571, #572.

🤖 Generated with Claude Code

---

Note

Low Risk
Test-only and workflow-only timeout additions with no production runtime or security logic changes.

Overview
Adds hard time bounds on external/network calls in CI so wedged API servers or stalled downloads fail fast instead of burning the full GitHub Actions job timeout (backend#1497).

In scripts/tests/e2e-seal-check.sh, point-in-time kubectl calls (get, run, logs, delete, describe) now use --request-timeout=10s. The existing kubectl wait with --timeout=180s is unchanged.

In .github/workflows/helm-ci.yaml, the pinned kubeconform tarball download adds --connect-timeout 15 and --max-time 120 on curl; retry and checksum verification behavior is unchanged.

^{Reviewed by Cursor Bugbot for commit 6bee53f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

Approving. Verified every kubectl in e2e-seal-check.sh is now bounded (--request-timeout=10s), the in-pod curl at L104 is bounded by -m 15, and the helm-ci.yaml download got --connect-timeout 15 --max-time 120 — no unbounded external call remains.

The deliberate exception — leaving kubectl wait without --request-timeout — is the right call: it's already bounded by --timeout=180s (a client-side deadline that fires even against a wedged server), and adding --request-timeout to its underlying watch would truncate the watch and cause flakes. Bounds mirror the repo's existing conventions. LGTM.