Auth concurrency: release HTTP pool slot before credential reject; thread cancellation to the credential path (stacked on #2046)

[tyrielv]

Stacked on #2046 — do not merge before it.
This PR branches off tyrielv/prefetch-auth-timeout (the head of #2046), not master.
Until #2046 merges, the diff shown here also includes that PR's single commit. Review
only the top commit ("Stop holding the HTTP pool slot across credential work; thread
cancellation to the credential path"). #2046 is still a draft and will be rebased, so
this branch will be rebased onto its new tip before it is ready.

What this changes

A six-lens review of #2046 found three pre-existing HIGH issues that the 120s credential
bound makes worse. They share one theme: do not hold shared locks and shared resources
while doing credential work. This PR does the two lower-risk ones (F06, F07). The third
(F04 — gitAuthLock held across the credential fetch) is a riskier monitor-lock redesign
and will follow as its own stacked PR.

F07 — thread CancellationToken to the credential path (always on)

Mount shutdown and user cancellation could not interrupt credential work, so a canceled
request could stay blocked for minutes before RetryWrapper observed the cancellation.

• SendRequest now passes its token to TryGetCredentials, ApproveCredentials, and
  RejectCredentials, then on through ICredentialStore and GitProcess to
  InvokeGitImpl.
• credentialGate.Wait now observes the token.
• InvokeGitImpl waits for the git child with a cancellation-aware poll loop, because
  Process.WaitForExit has no token overload. On cancellation it kills the process tree
  and throws OperationCanceledException, so RetryWrapper aborts promptly instead of
  retrying. Callers that pass no token keep the previous behavior.

F06 — release the connection-pool slot before the reject leg (off by default)

On a 401, RejectCredentials can block for a long time on a slow or hung credential
helper while SendRequest still holds a process-wide connection-pool slot. Under
parallel 401s every slot can be occupied by a thread waiting on credentials, so healthy
interactive hydration fails on the 30s pool-wait even though the network is fine.

• The error body is already buffered into errorMessage, so SendRequest now frees the
  slot before the reject leg runs.
• Gated behind the new off-by-default flag gvfs.release-connection-before-credential-reject,
  per the repo convention for risky runtime changes during stabilization ships.
• The finally block does not release a second time if a reject that ran after the early
  release then throws (for example on cancellation).

Tests

Six new tests pin the new invariants:

• Cancellation interrupts a blocked credential fetch and a blocked reject-reload.
• The caller's token reaches the git invocation.
• The pool slot is released before the reject leg when the flag is on, and held when it
  is off.
• The slot is released exactly once when a reject is canceled (no double-release).

HttpRequestorTests drives the real SendRequest through an injected HttpMessageHandler
and a MockGitProcess that can block until signaled or canceled. Each assertion was
mutation-tested: reverting the matching fix makes exactly the intended test fail.

Full unit suite: 908 tests, 0 failed. StyleCop clean.

Notes for review

• InvokeGitImpl throws OperationCanceledException on cancellation rather than returning
  a failure Result. This is deliberate: returning a failure would make RetryWrapper
  retry, which is wrong for a canceled operation. RetryWrapper does not treat
  OperationCanceledException as retryable, so it aborts.
• F06 is behind a flag; F07 is always on because it only extends cancellation reach and
  does not change behavior when no cancelable token is passed.