Stabilize OpenWrt container CI for variable TLS fetch exit codes

[Copilot]

The OpenWrt Compile container (22.03.6) job was failing in the negative TLS test path, not because the request succeeded, but because uclient-fetch returned a different non-zero code than the script expected. This change makes the test assert failure semantics instead of overfitting to a single exit code for untrusted-root.badssl.com.

• Root cause

  • Docker/OpenWrt/runTests.sh hard-coded exit code 5 for uclient-fetch 'https://untrusted-root.badssl.com/'.
  • In the 22.03.6 container image, the same rejected TLS connection can surface as exit code 4 (Connection reset prematurely).

• Test helper update

  • Generalized runCMD() to accept a set of allowed return codes.
  • Switched the untrusted-root.badssl.com assertion from 5 to 4 5.

• Shell hardening

  • Cleaned up the helper’s temporary file on both success and failure paths.
  • Quoted temp-file paths and simplified matching logic to avoid fragile word-splitting behavior.

• Behavioral impact

  • Positive-path checks remain strict.
  • Negative TLS coverage remains intact: the request must still fail, but the helper now tolerates the two observed OpenWrt failure modes.

# before
runCMD "uclient-fetch 'https://untrusted-root.badssl.com/'" 5

# after
runCMD "uclient-fetch 'https://untrusted-root.badssl.com/'" "4 5"

[wolfSSL-Bot]

Can one of the admins verify this patch?