Sparse checkout sometimes gets a different commit than normal checkout.

Looking at the CI logs of for PR [#34082](https://github.com/Azure/azure-sdk-for-net/pull/34082) at https://dev.azure.com/azure-sdk/public/_build/results?buildId=2596188&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=e77055a3-6358-5204-c080-7a2e41553284 I see the following:

1) The Build job used the standard checkout and used the following commits:
HEAD is now at 5281ed1c6c Merge 175eba870b1fae1f5e07b0981b359431b356fee2 into a84139d132da2372e81f96e1b5891fd00454162c
https://github.com/Azure/azure-sdk-for-net/commit/5281ed1c6c

2) The Analyze job used the sparse checkout and used the following commits:
HEAD is now at df6b4c15d1 Merge 175eba870b1fae1f5e07b0981b359431b356fee2 into 4d8a0979d83ffd6f52e97b3eeeab28858f50ccba
https://github.com/Azure/azure-sdk-for-net/commit/df6b4c15d1 which was one commit change earlier than the build job.

Looks like we use Build.SourceVersion in our template https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/pipelines/templates/steps/sparse-checkout.yml#L9. Perhaps that isn't always set correctly, or perhaps there is some race-condition when the refs/pull//merge gets updated between when these jobs ran.

IIRC there might also be some difference in Build.SourceVersion depending on if the PR was from a fork or not. Something to consider but I wouldn't over pivot on that fact.