Merge queue failures too frequent and don't fail loud enough

[guineveresaenger]

Recent example: #1333

My experience:
I hit "add to merge queue" after tests passed and assumed it would merge.

However, the PR got quietly kicked off due to an internal server error around pulumi-xyz, causing an overnight delay of fixing a release-blocking issue in pulumi-gcp:

It is not obvious that a PR author should:

1. Wait for tests to pass
2. Add to merge queue
3. Ensure the PR remains in the merge queue via manually continuing to check back until the PR is merged.

Also, this procedure is clunky.

There should be:

• automatic retries
• alerts
• fewer actual tests on the merge queue?
• ??

Also - that is one heck of a merge queue time:

[danielrbradley]

The merge test is quite slow because we're exercising all the provider workflows through the process of open a PR, merging it to master, then cutting a real release of the provider.

Here's the actual failure in the release test: https://github.com/pulumi/ci-mgmt/actions/runs/13060295740/job/36441608805#step:8:26041

failed to get jobs: HTTP 503: 503 Service Unavailable (https://api.github.com/repos/pulumi/pulumi-xyz/actions/runs/13060588520/jobs?per_page=100)

It looks like it issue was the GitHub API going offline.