Use of `FETCH_HEAD` is unreliable in conjunction with multiple refspecs in `BUILDKITE_REFSPEC`

**Is your feature request related to a problem? Please describe.**
We would like to set `BUILDKITE_REFSPEC` to our main branch and whatever branch is currently being built (assuming it is another branch). We have run into multiple issues with this where [`FETCH_HEAD`](https://github.com/buildkite/agent/blob/32e37f2dff3d58066b3667cc91cfd94d0f2f57a9/internal/job/checkout.go#L561-L569) doesn't end up pointing to the right branch and instead points at master under some circumstances, notably, if doing a rebuild. It seems like `git fetch ref1 ref2` creates two lines in `.git/FETCH_HEAD` and then when `git checkout FETCH_HEAD` is done, either of the refs will be used, sometimes landing on master instead of the feature branch.

**Describe the solution you'd like**
A way to set narrow refspecs and have the correct branch checked out, deterministically.

**Describe alternatives you've considered**
We could:
- Use completely custom checkout/clone logic, but that seems like a downgrade
- Not use narrow refspecs (will cause some slowdown since our monorepo has thousands of branches and can be slow to update)
- Possibly disable the resolve commit feature? I am unsure if this is related

**Additional context**
I believe we are currently using [this experiment](https://buildkite.com/docs/agent/v3#experimental-features-resolve-commit-after-checkout), if that is related.

Start in internal/job/checkout.go around lines 561-569, then review the linked documentation for the resolve-commit-after-checkout experiment and reproduce the multiple-refspec FETCH_HEAD behavior. Done means narrow BUILDKITE_REFSPEC values deterministically check out the intended branch, including during rebuilds.

Written by the indexing model from the issue text.