Silent Git auto-fetch can still open Git Credential Manager dialogs

## Type: Bug

## Summary

Git auto-fetch uses `silent: true`, but Git Credential Manager can still open interactive authentication dialogs. This is especially disruptive when a workspace contains a parent repository and initialized submodules on the same HTTPS host: each repository has its own `AutoFetcher`, so their initial fetches may overlap when an OAuth access token expires.

## Reproduction

Tested on Windows 11 with VS Code 1.121.0, Git 2.53.0.windows.1, GCM 2.7.0, and GitLab HTTPS remotes:

1. Open a folder containing a parent repository and several initialized same-host submodules.
2. Let the GitLab OAuth access token pass its two-hour lifetime.
3. Reopen the folder with `git.autofetch` enabled.

The independent initial auto-fetches overlap. In our trace one GCM process refreshed the rotating token successfully while two others opened `Connect to GitLab` dialogs. These were background auto-fetches, not user-initiated commands.

## Implementation gap

* `autofetch.ts` invokes `fetchDefault({ silent: true })` or `fetchAll({ silent: true })`.
* `repository.ts` creates an `AutoFetcher` per opened repository; idle checks are repository-local.
* `git.ts` maps `silent` only to `VSCODE_GIT_FETCH_SILENT=true`.
* `askpass-main.ts` consumes that private variable, but GCM does not. GCM uses `GCM_INTERACTIVE` / `credential.interactive` to decide whether UI is allowed.

## Expected behavior

A silent background auto-fetch should not open browser or GUI authentication. Cached credentials and silent token refresh should continue to work.

## Suggested short-term fix

For `silent: true` fetches, also pass `GCM_INTERACTIVE=0`. This is narrower than disabling `git.autofetch`, which removes desired functionality. Host-level coordination between repository auto-fetchers and a standardized Git protocol signal can be considered separately.

There is a complementary GCM provider bug in which a losing operation may erase newer GitLab credential state; that should be fixed in GCM, but does not remove VS Code's responsibility to keep silent background work non-interactive.

## Related

* Traced GCM reproduction: https://github.com/git-ecosystem/git-credential-manager/issues/1555#issuecomment-4534488634
* Earlier VS Code report without this trace or diagnosis: https://github.com/microsoft/vscode/issues/205707