test(e2e): post-install-prep bounds its waits and not the calls that do the work #3708

The waits in hack/e2e-post-install-prep.sh are budgeted. The calls that act are not. If one of them stops returning, the install step does not fail — it stops.

Bounded today: the two wait_for calls run kubectl wait --timeout= against the deadline set at line 22; the LINSTOR node loop carries node_deadline at line 80; the MetalLB CRD wait is timeout 300 sh -ec … at line 142.

Not bounded: kubectl exec … linstor sp l at line 93; the three backgrounded kubectl exec … linstor ps cdp at line 99, collected afterwards with a bare wait "$pid"; and the two kubectl apply -f - at lines 107 and 145.

Two more are bounded only in appearance. kubectl exec … linstor node list at line 82 and kubectl get endpoints at line 56 sit inside the node loop, and that loop consults its deadline between iterations. A single call that never returns outlives the 300s budget the loop exists to enforce, because the check it would trip is on the other side of the call.

How this presents matters more than the missing flag. The caller blocks at hack/e2e-install-cozystack.bats:247, so a call that never returns does not produce a failed step. It produces a step that does not end, and the run is closed by the job's own timeout-minutes instead of by the test. A failing step and a job killed at its ceiling are different paths, and they do not leave the same evidence behind.

Not established, and worth saying plainly: I have not observed this failure mode. No run history was searched for it, and I did not check whether the report-collection steps, which carry if: always(), still run when a job is cancelled at its ceiling. This is a hypothesis about a missing bound, not an incident.