Let the runner do the full blobless clone for Duo Agent Platform flows

What does this MR do and why?

The dap_full_clone path currently sets GIT_STRATEGY=none and runs its own git clone in the job. That forced a few workarounds — git must be in the job image (breaks slim images like AI Gateway, since setup_script runs after the clone), a credential.helper, manual proactiveAuth, and a .dap-tmp cache-move dance.

This MR lets the runner do the clone instead — a full (GIT_DEPTH=0) blobless (--filter=blob:none) clone with the runner's own git — and then re-attaches HEAD to a named branch once setup_script has run. This keeps the full-clone benefits (full history, base ref, no git fetch --unshallow) and the blobless latency win, while removing the git-in-image requirement and the credential-helper / cache-move workarounds.

The flag applies to all flows (not just developer/v1), and everything stays gated behind dap_full_clone.

Idea originated here: #602558 (comment 3556680669)

How it works

• git_clone_variables (full-clone): GIT_DEPTH=0 + GIT_FETCH_EXTRA_FLAGS=--filter=blob:none (+ GIT_LFS_SKIP_SMUDGE) — the runner clones with its helper git. No GIT_STRATEGY=none.
• After setup_script, workspace_fixup_commands runs git checkout -B <source-or-default branch> (the runner leaves a detached HEAD) and a blob-free fetch to populate the base ref.
• Auth uses the runner's clone + the existing oauth_remote_commands (now used for full-clone too); the credential.helper is gone. proactiveAuth still applies to the agent's git ops.
• Commands are regrouped into coding_environment_commands (repo setup) and executor_commands (always-on). This is behavior-preserving when the flag is off; when the flag is on, the workspace_fixup_commands (HEAD re-attach + base-ref fetch) are inserted between the oauth remote setup and the workflow commands.

No behavior change unless dap_full_clone is enabled.

How to test locally (GDK)

1. Use a project backed by a repo with real history (a shallow/partial import won't exercise blobless). A slim image (no git) is a good choice — it proves the git-in-image requirement is gone (AI Gateway is a good testing candidate since its agent config uses a slim image).

2. Enable the flag:

   Feature.enable(:dap_full_clone)

3. Trigger any Duo Agent Platform flow (mention the service account on an issue or an MR).

4. Open the duo_workflow CI job log and confirm:

   • Fetching changes... (runner clone, no git depth set to 1),
   • no Skipping Git repository setup, no $ git clone in step_script,
   • git checkout -B "…" → Switched to a new branch '…' (attached; MR run → MR source branch, issue run → default branch),
   • the git_unshallow step is a no-op (is-shallow-repository is false).

5. (Optional) Confirm the workspace from the agent's view — mention the flow with:

   Do NOT change code. Report: git rev-parse --abbrev-ref HEAD, git rev-parse --is-shallow-repository, git config --get remote.origin.promisor, git rev-list --objects --all --missing=print | grep -c '^?', and whether git log origin/main..HEAD and a push of a scratch branch succeed.

   Expect: a named branch, false, true, a non-zero deferred-blob count, and working base-branch ops + push.

6. Disable when done: Feature.disable(:dap_full_clone).

Follow-up (out of scope)

Once this has run behind the flag on .com for a few days, make the blobless clone the default and remove the shallow-clone path and the dap_full_clone flag — the small-repo comparison showed shallow has no startup advantage, so there's no reason to keep it. Doing this separately keeps the change reversible while we watch prod (incl. the one-time lazy-fetch cost of deep-history ops like blame/rebase, which we still want to measure at monolith scale).