Orchestrator readiness probe never runs: wait_for.sh invoked with no args

[jeroenubbink]

Summary

services_required: true scenarios never actually pass through the orchestrator's readiness wait — the step fails immediately and the whole run bails with readiness probe failed.

Root cause

runner/orchestrate.py:_wait_for_services() invokes the script with no arguments:

proc = subprocess.run(
    ["bash", str(WAIT_FOR_SCRIPT)],   # no <name> <url>
    cwd=str(REPO_ROOT),
    ...
)
return proc.returncode == 0, proc.stdout + proc.stderr

but scripts/wait_for.sh requires them:

# Usage: wait_for.sh <name> <url> [timeout_seconds]
set -euo pipefail
NAME="${1:?service name required}"
URL="${2:?URL required}"

With set -u and the ${1:?...} guard, the script exits non-zero before polling anything. _wait_for_services() returns (False, ...), and the caller treats it as a hard error:

wait_ok, wait_out = _wait_for_services()
...
if not wait_ok:
    overall_status = "error"
    error_message = "readiness probe failed"
    teardown_logs_needed = True
    return run_id

So every services_required: true scenario (swap_foreign_mint, swap_foreign_mint_retry, topup_input_fee, …) is collectable but never runs end-to-end through the harness. Direct-pytest verification sidesteps the orchestrator, which is why local runs look green.

Doc mismatch

The orchestrate module docstring calls this step "best-effort ... warnings, not crashes", but the code returns early with overall_status = "error". Either the wiring should match the docstring (warn + continue) or the docstring should be corrected.

Fix options

1. Iterate the compose services and call wait_for.sh <name> <url> per service (the script is per-endpoint by design), or
2. Make _wait_for_services() treat a probe failure as best-effort (log a warning, proceed) to match the docstring, and rely on compose healthchecks + per-scenario readiness.

Split out from the review of the trusted-mint input-fee test PR (fix the test PR now, address the pre-existing wiring here).