ci(release): wait for the tagged commit's CI instead of reading it as failed

[kingchenc]

The publish gate asks the API for conclusion on the tagged commit's ci.yml
run and requires success. A run that is still going reports null there, and
the check treated that the same as a failure -- so a tag pushed two minutes after
its merge, with CI still queued behind the release run's own build jobs, was
rejected for having "no successful ci.yml run". That is what happened to v1.0.4:
the commit was fine, went green 32 minutes later, and a rerun published it with
no change at all.

Nothing was published in the meantime, so the gate did its job. Its verdict was
still wrong, and the distinction it missed is the one that matters: not decided
yet is not decided against. The step now polls until the run settles, bounded to
45 minutes, and says what it is waiting on. Any conclusion other than success
still fails on the spot, so a genuinely broken commit is refused as fast as
before -- only the undecided case waits. timeout-minutes on the job moves from
10 to 60 so it outlives the wait it now performs.

This also removes the reason to rush a tag. Tagging early mattered because
r-universe builds the R binding from main and resolves its C ABI from the
release matching DESCRIPTION, so a bump left untagged puts those builds on a
404; waiting for CI first spent 25 to 55 minutes of that window. The gate now
holds the tag for as long as it needs, and neither constraint has to be timed by
hand.

Written and linted, not run: release.yml executes only on a pushed v* tag,
so the next release is the first time this path is exercised.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!