ci: retry faucet funding with a new wallet

[TheLastCicada]

Summary

• Live-API jobs now share scripts/ci-faucet.sh instead of 11 copied Faucet steps.
• If the wallet is still unfunded after the existing 10-minute wait, the script deletes the key, restarts wallet / data / data_layer_http, and requests faucet funds for a new address.
• That recreate-and-refill cycle runs up to 3 wallets. The faucet will not pay the same address twice, so a new key is required for each retry.

Test plan

• Confirm a live-API job that gets funded on the first wallet still passes the Faucet step (no recreate in the logs).
• Confirm a live-API job whose first wallet stays at balance 0 for 10 minutes deletes the key, starts a new wallet, and requests faucet funds again.
• Confirm the job fails only after 3 unfunded wallets, and that wallet / data / data_layer_http are restarted on each retry.

---

Note

Low Risk
CI-only workflow and script changes; no application runtime impact, though live-API job reliability depends on the new retry/stop logic behaving correctly.

Overview
Live-API GitHub Actions jobs no longer embed duplicate Faucet bash in tests.yaml; each Faucet step now sets TESTNETA_FAUCET and runs scripts/ci-faucet.sh.

The script keeps the previous behavior (wallet readiness, up to five faucet HTTP attempts, then up to ~10 minutes of balance polling) and adds up to three wallet attempts: if funds never arrive, it stops wallet/data/data_layer_http, deletes keys, generates a new labeled wallet, restarts services, and requests faucet funds again—because the testnet faucet won’t pay the same address twice.

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