Bound runtime credential fetch so prefetch can't hang on auth

[tyrielv]

Problem

A user missed a Git Credential Manager auth popup (it was behind another window). Instead of timing out, GVFS waited indefinitely. The blocked operation was the mount's background maintenance PrefetchStep (not user-initiated), which holds the shared prefetch-commits-trees.lock on the gvfs object cache. Because that lock was never released, a subsequent user-initiated gvfs prefetch blocked behind it forever.

Root cause

Runtime credential fetches flow through:

HttpRequestor.SendRequest
  -> GitAuthentication.TryGetCredentials(tracer, out cred, out err)
  -> GitAuthentication.TryCallGitCredential(tracer, out err)   // timeoutMs defaulted to -1
  -> GitProcess.TryGetCredential(..., timeoutMs: -1)
  -> InvokeGitImpl(... timeoutMs: -1) -> Process.WaitForExit(-1)  // infinite

The mount startup auth path was already bounded (credentialTimeoutMs on TryInitializeAndQueryGVFSConfig), but the runtime path — used by every object/pack download, including the background maintenance prefetch — was never given a finite timeout. The timeout plumbing already exists end-to-end in GitProcess/InvokeGitImpl; the runtime path simply never passed a finite value.

The mount's maintenance prefetch and on-demand hydration share one GitObjectsHttpRequestor / one GitAuthentication, so bounding the shared runtime path fixes the maintenance-prefetch hang.

Fix

1. Bound every runtime credential invocation

• TryGetCredentials takes credentialTimeoutMs and plumbs it to TryCallGitCredential.
• RejectCredentials — which reloads the credential on the 401-retry leg — takes and plumbs the same timeout. This leg is the actual stale-token hang path.
• ApproveCredentials and the ICredentialStore store/delete operations are bounded too. git credential approve and git credential reject previously ran with timeoutMs = -1 while holding gitAuthLock, so a stalled helper could still pin the prefetch lock forever even after the fill leg was bounded.
• HttpRequestor exposes a protected virtual int CredentialTimeoutMs and passes it to all three.

2. The gate must outlast the fetch it serializes

TryCallGitCredential waited a fixed 60s on credentialGate, and on expiry fell through and spawned a second credential fetch. With a 120s fetch bound that guaranteed a second, competing GCM prompt in exactly the slow-prompt case the longer bound exists to tolerate. The gate now waits at least as long as the fetch.

3. A timeout no longer burns the retry budget

SendRequest previously returned shouldRetry: true for every credential failure, so one timeout could consume the whole RetryWrapper budget (up to MaxAttempts x 120s), re-prompting the user each time. TryGetCredentials now reports whether the failure was a timeout, and SendRequest sets shouldRetry accordingly. Genuine auth failures still retry exactly as before.

4. Kill the process tree, not just git.exe

On timeout InvokeGitImpl called Process.Kill(), which left the credential-helper child alive — holding the credential store and showing orphaned prompt UI. It now kills the whole tree, then waits (bounded) so the async stdout/stderr readers flush before their buffers are read.

5. Configurable, with an escape hatch

The bound lives on RetryConfig (default 120s), overridable via gvfs.credential-timeout-seconds; 0 or less restores the historical unbounded wait.

RetryConfig is already loaded once per process from git config and already passed into the HttpRequestor constructor alongside MaxRetries/Timeout, so this adds no config I/O at requestor construction — no git config spawn on the mount startup path, and no new unbounded git invocation (GetFromConfig itself runs unbounded, which is the very class of call this PR removes).

6. Measurable in the field

The timeout emits a distinct CredentialFetchTimedOut event with structured timeoutMs/RepoUrl fields rather than only warning text — so we can measure how often the bound fires, and correlate a timeout with a later successful fetch (a prompt that got cut off) versus none (a hang that was prevented).

Why 120s and not 30s: the mount's requestor is shared by the background maintenance prefetch, interactive on-demand hydration, and the user-initiated gvfs prefetch/clone verbs. A 30s bound risks converting today's hang into a spurious auth failure when a human is legitimately slow to answer a GCM cold-start / MFA / smartcard prompt. 120s still bounds the indefinite hang — the reported case was a prompt never answered — while giving a noticed prompt ample time.

On timeout, TryGetCredentials returns false and engages backoff. The download gives up, TryDownloadPrefetchPacks returns false, and PrefetchStep releases prefetch-commits-trees.lock — unblocking the user-initiated prefetch — instead of hanging forever.

Compatibility

ICredentialStore.TryGetCredential gains a required out bool timedOut parameter (needed to tell a timeout apart from a genuine auth failure). GitProcess is the only implementer and GitAuthentication the only caller, both updated here. The remaining new parameters are optional with defaults, and CredentialTimeoutMs is virtual, so all other callers compile unchanged.

Tests

• TryGetCredentialsTimesOutWhenCredentialManagerDoesNotRespond — asserts the timeout reaches InvokeGitImpl and is rendered in the message, not just that some failure occurred.
• RejectCredentialsBoundsTheCredentialReload — the 401-reject leg bounds both the credential reload and the erase (no invocation left at -1).
• TryGetCredentialsReportsTimedOutOnlyForTimeouts — a generic auth failure is not reported as a timeout, so real failures still retry.
• RetryConfig coverage for the default, an explicit value, the non-positive unbounded escape hatch, and a guard that hand-built RetryConfigs still get a bounded default.
• MockGitProcess now records the timeout passed to each git invocation, which is what makes the above assertions possible.

Mutation-verified: the two central tests were confirmed to fail when the fix is reverted — removing the credentialTimeoutMs plumbing, and removing the timedOut signal.

Full suite: 930 tests, 919 passed, 0 failed (11 pre-existing ignored); builds with 0 warnings / 0 errors.