test(e2e): the post-install-prep failure-path diagnostics can hang the install they are meant to explain #3707

hack/e2e-post-install-prep.sh gives up on the LINSTOR node wait after its own 300s budget and then reads two objects to say why. Neither read carries a bound, and the path they sit on runs only when something has already gone wrong.

Lines 85 and 86:

kubectl get endpoints linstor-controller -n cozy-linstor -o wide >&2 || true
kubectl get pods -n cozy-linstor -o wide >&2 || true

|| true covers a read that fails. It does nothing for a read that never returns. The script runs in the background of the install step and its caller blocks on it at hack/e2e-install-cozystack.bats:247 (if ! wait $POST_PREP_PID; then), so a read that hangs does not fail the install — it holds it open, on the one path that only executes when the cluster is already unhealthy and a read is least likely to come back.

The same shape sits one function earlier: controller_reachable at line 56 reads kubectl get endpoints on every iteration of the node loop, also unbounded, and that one runs on the healthy path too.

The fix is the form used elsewhere in the tree: an outer timeout with a smaller --request-timeout inside it, so kubectl gets to name the reason before the outer kill takes it away. Equal values would make the kill land first and lose the reason.

Not established: whether either read has ever actually hung. I read this out of the code and did not search run history for an install step that ended at the job's ceiling, so this is a gap in the bound rather than a report of an incident.

Related but not the same defect: #3680 is about the install phase collecting the fact of a failure and not its reason. This is about the collection itself being able to wedge the step.