`refs/pull/%s/head` might not always be there, but if it is missing, buildkite fails the checkout

Based on our recent observations, github creates `refs/pull/%s/head` asynchronously and sometimes these creations queue up enough that the ref will not be there by the time buildkite receives the webhook and proceeds.

Unfortunately if the provider is github and we're building the PR, buildkite agent completely fails the job if it is unable to fetch the `refs/pull/%s/head` even the refspec is not even guaranteed to match the commit we're building (I can update between the time original webhook is issued and when the job runs, for example when retrying old job, or even when developer pushes new commit and the build is not configured to cancel)

The main fetch:
https://github.com/buildkite/agent/blob/e55e764ab2ada4b730faa8acd68defc1f3044253/internal/job/checkout.go#L578

Mirror update logic:
https://github.com/buildkite/agent/blob/e55e764ab2ada4b730faa8acd68defc1f3044253/internal/job/checkout.go#L386

Proposed solution: allow this fetch to fail and proceed as long as we still can fetch the specific refspec here:
https://github.com/buildkite/agent/blob/e55e764ab2ada4b730faa8acd68defc1f3044253/internal/job/checkout.go#L580

Note that mirror logic does not mirror the same dual-fetch, but it also can fail the build if the `refs/pull/%s/head` is not there yet, so it needs to be expecting this corner case too.

Start in internal/job/checkout.go at the main fetch around line 578 and the mirror update logic around line 386. Trace how the GitHub refs/pull/%s/head fetch interacts with the specific refspec fetch, including mirror updates. Done means a missing pull ref does not fail checkout when the specific refspec can still be fetched, and mirror handling covers the same case.

Written by the indexing model from the issue text.