fix(wait): stop sharing exit code 2 with Click's usage errors

[gaurav02081]

Follow-up to #3. Three things, one of which I think matters.

The exit code collides with Click's

run wait uses 2 for a timeout, but Click already exits 2 on any usage error. Verified against the built command:

sp run wait                      -> 2   (missing argument)
sp run wait --nosuchflag         -> 2   (unknown option)
sp run wait 9412 --interval 3    -> 2   (below the minimum)
sp run wait 9412                 -> 2   (timeout)

That undoes the feature's own promise — "a script can gate on the outcome without parsing anything". Written the obvious way:

sp run wait $ID
case $? in 0) merge ;; 1) block ;; 2) sleep 600; retry ;; esac

a mistyped --timeout reads as "still running", and the script retries forever a command that never made an API call. Nothing crashes, nothing is printed — it just takes the wrong branch silently.

Timeout is now 9. The README's table stopped at 8 and skipped 2 already, which is why the gap was there; both facts are now written down.

The payload shape depends on the argument count

payload = rows[0] if len(rows) == 1 else {'data': rows}

So sp run wait $IDS | jq '.data[]' works until the list happens to hold a single run. Every other list in the CLI is {'data': [...]} whether it has one row or a hundred; wait now matches.

A pass is not proof of coverage

Noted in the docstring rather than changed. The API derives run status from the result rows that exist, not the ones expected, so a run that recorded 1 of 237 samples still reports pass — production run 9360 does exactly that. Worth knowing for a command whose whole job is gating a script.

Testing

Two new tests: one asserting usage errors and a timeout are distinguishable, one that the payload is a collection either way. Updated the existing timeout test. 218 pass; isort/pycodestyle/pydocstyle/mypy clean.

Nice work on the command itself — the stderr/stdout split and treating an unknown status as terminal are both the right calls.