test: the --request-timeout guard does not scan hook scripts kept under packages/*/*/files/ #5304

The guard against --request-timeout on in-cluster kubectl calls only looks at chart templates, so a hook script kept as a separate file passes it with the flag in place. hack/check-hook-request-timeout.bats collects its candidates with grep -rl 'kubectl' packages/*/*/templates/ (check-hook-request-timeout.bats#L33). A chart that loads its script with .Files.Get "files/<name>.sh" into a ConfigMap never reaches that list, although the script runs in a hook Job with the same in-cluster credentials.

This let the flag through in #4915. Its first revision of packages/system/seaweedfs/files/orphan-identities.sh passed --request-timeout=30s to all three kubectl calls, and the guard passed. In the cluster, the BucketAccess listing would always have gone to localhost:8080 and failed, so the hook would have removed nothing, written no Event and exited 0, which is the #4288 failure again. A review caught it, not the guard. On main, packages/system/cilium/files/ipam-migration.sh is a hook script in the same blind spot, and #4893 adds packages/system/seaweedfs/files/object-lock-actions.sh.

The check matches only the --request-timeout=<value> form, so --request-timeout 30s with a space also passes. kubectl accepts both.

Fix shape: add packages/*/*/files/ to the candidate list, skipping files that are not shell scripts or that name KUBECONFIG, as templates already are. Match both the = and the space form, with any value other than zero.

A test that fails on the current code: a bats case that runs the guard on a temporary tree containing packages/x/y/files/hook.sh with kubectl get pods --request-timeout=30s, and expects it to fail.