bootstrap: fix inverted success check in PowerShell download fallback

[SebTardif]

When curl fails on Windows and bootstrap falls back to PowerShell for downloads, the success/failure check is inverted: the code returns early on failure (is_failure()) and prints "spurious failure, trying again" on success, then exits with code 1 after three successful downloads.

This was introduced in #141909 during the ExecutionContext refactoring. The original code used self.try_run(...) which returned bool (true = success). The refactoring changed the return type to CommandOutput but used is_failure() for the early-return check, inverting the logic.

The fix changes the check from is_failure() to is_success(), restoring the original behavior: return early when the download succeeds, retry when it fails.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @clubby789 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: bootstrap
• bootstrap expanded to 6 candidates
• Random selection from Mark-Simulacrum, clubby789, jieyouxu

[clubby789]

Would you remind removing the commit description? It's very verbose for a one-line change that's fairly self evident. Otherwise r=me

[clubby789]

@bors r+ rollup

[rust-bors]

📌 Commit 893a9f8 has been approved by clubby789

It is now in the queue for this repository.

[clubby789]

I guess this code hasn't been hit much; it seems surprising this wasn't noticed before

[ChrisDenton]

The chances of both curl and powershell failing are pretty slim. I guess the exception being if there's a genuine connection error but then the user would still see the download failed (via the progress message). They'd just get an unhelpful "file not found" error afterwards when bootstrap tries to move the downloaded file.