Pass proactiveAuth to git checkout for partial-clone lazy fetches

What does this MR do?

When FF_USE_GIT_PROACTIVE_AUTH is enabled, pass -c http.proactiveAuth=basic to git checkout in addition to git clone and git fetch.

In partial-clone repositories, git checkout can trigger a lazy fetch from the promisor remote to retrieve missing objects. That lazy fetch is a separate HTTP request that does not inherit -c flags from the original clone/fetch invocation, so the username is not propagated to Gitaly during those fetches.

Changes:

• shells/abstract.go (writeCheckoutCmd): build checkout args dynamically, conditionally including http.proactiveAuth=basic
• functions/concrete/run/stages/get_sources.go (gitCheckout): same change for the functions path
• shells/abstract_test.go: add TestGitProactiveAuthCheckout covering enabled/disabled cases

Why was this MR needed?

See this discussion (internal link)

writeCheckoutCmd and gitCheckout hard-code only -c submodule.recurse=false and never check the UseGitProactiveAuth feature flag. The clone and fetch paths already pass this flag, but checkout was missed. This means that in partial-clone setups where checkout triggers a lazy fetch, the proactiveAuth setting is not applied, and the username is not propagated to Gitaly.

Observed in https://gitlab.com/gitlab-org/gitlab/-/jobs/14101195927 where FF_USE_GIT_PROACTIVE_AUTH:true was set and a lazy fetch during checkout failed without the proactiveAuth config.

What's the best way to test this MR?

1. Run the new TestGitProactiveAuthCheckout unit test:

   go test -run TestGitProactiveAuthCheckout ./shells/ -count=1

2. Verify existing TestGitProactiveAuth (clone path) and TestGitCleanFlags (checkout path) still pass.
3. For an end-to-end check, enable FF_USE_GIT_PROACTIVE_AUTH on a runner and run a job against a partial-clone repository. Confirm the checkout step's git command includes -c http.proactiveAuth=basic using CI_DEBUG_TRACE: "true"

What are the relevant issue numbers?