TortoiseGit least-privilege auth on shared Windows: GCM HTTPS tokens or Pageant SSH keys?

We run TortoiseGit on shared Windows workstations where several developers use the same machine, and we need to pick one authentication approach that keeps credentials as tightly scoped as possible. The two documented paths are HTTPS through Git Credential Manager, which stores per-host tokens in Windows Credential Manager, and SSH through Pageant with per-repository deploy keys.

Each option has a trade-off we cannot resolve from the documentation alone. GCM tokens can be fine-grained and short-lived, and expiry normally triggers an interactive re-prompt, but a stale Credential Manager entry can cause repeated silent failures. Pageant keys avoid token storage entirely, yet a decrypted key stays in memory for the whole login session, and a revoked key just returns "permission denied (publickey)" with no recovery prompt. TortoiseGit's SSH client setting (TortoiseGitPlink vs OpenSSH) also changes which agent and key format applies.

There appears to be no TortoiseGit-level mechanism for per-user credential isolation beyond separate Windows profiles, so the enforcement burden falls on whichever store we choose.

Given a shared-machine constraint, which approach gives stronger least-privilege guarantees: per-user GCM tokens or per-session Pageant keys? How should expired-credential recovery differ between the two in day-to-day operation? Does the TortoiseGitPlink versus OpenSSH choice materially change the isolation story?