Wire source_resolver into resolver and download pipelines

[LalatenduMohanty]

PR #938 defines a model layer for declarative source configuration with provider classes, a RetrieveMethod enum, and discriminated union dispatch. This issue tracks wiring that model layer into the runtime so YAML-configured providers are used by the resolver and download pipelines.

Work items:

1. Modify default_resolver_provider() in resolver.py to check pbi.source_resolver before returning PyPIProvider
2. Modify default_download_source() in sources.py to detect git+https:// / git+ssh:// URLs and route to the git clone path
3. Add remove_dot_git field to GitOptions
4. Connect git_options (submodules, submodule_paths, remove_dot_git) to the git clone download path

Plugin precedence is preserved — overrides.find_and_invoke() calls the plugin hook first. The source_resolver check only runs when no plugin exists.

See: #937, #938, #936

[tiran]

Your ticket is a couple steps ahead. First the proposal needs to be approved. Next I'll update and push my configuration scaffolding. Then we can implement the logic and integrate it with the rest.

[LalatenduMohanty]

The proposal #938 has merged. We are waiting for #1052 to land and then we can work on this issue.

[smoparth]

After adding remove_dot_git field to GitOptions with default to True, caused .git to be removed after all git clones, including existing req.url flows. With .git removed, setuptools-scm cannot determine the version and fall back to 0.0.0, causing wrong version appended to package names ex: stevedore-0.0.0.tar.gz '0.0.0' over public version '5.2.0'.

For backward compatibility defaulted remove_dot_git to False

[smoparth]

After adding remove_dot_git field to GitOptions with default to True, caused .git to be removed after all git clones, including existing req.url flows. With .git removed, setuptools-scm cannot determine the version and fall back to 0.0.0, causing wrong version appended to package names ex: stevedore-0.0.0.tar.gz '0.0.0' over public version '5.2.0'.

For backward compatibility defaulted remove_dot_git to False

Adding some notes for reference

Many Python packages use a tool called setuptools-scm to automatically determine their version number. Instead of hardcoding version = "5.2.0" in pyproject.toml, they write:

[tool.setuptools_scm]
And setuptools-scm figures out the version by looking at git tags. It checks two sources, in order:

The .git directory, it runs git describe --tags to find the nearest tag
A .git_archival.txt file, a fallback text file that records the tag/commit info
When you clone a repo and build it normally, .git exists, setuptools-scm reads the tags, and produces the correct version like 5.2.0.

What happens with our remove_dot_git: true:

Fromager clones stevedore at tag 5.2.0
Our code removes .git (because remove_dot_git: true)
Build step runs, setuptools-scm tries to find the version
No .git directory -- can't run git describe
No .git_archival.txt file either -- nothing to fall back to
setuptools-scm gives up and returns 0.0.0
The built sdist is named stevedore-0.0.0.tar.gz
Fromager's validation says: "expected 5.2.0, got 0.0.0" -- crash
This is exactly what broke the CI in PR #1202.

The fix: After removing .git, write a .git_archival.txt file that tells setuptools-scm what the version is. The file looks like this:

node: abc123def456...
node-date: 2026-06-22T10:00:00+00:00
describe-name: v5.2.0
ref-names: tag: v5.2.0
setuptools-scm reads this file, sees describe-name: v5.2.0, and correctly produces version 5.2.0.

Why it's tricky: At the point where we remove .git, we need to know the tag name and commit hash. The resolver already has this info (the Candidate object has remote_tag="v5.2.0" and remote_commit="abc123..."), but this info isn't passed down to download_git_source(). That plumbing needs to be added.

Without .git_archival.txt generation, removing .git is unsafe. So we keep .git by default until this issue is resolved.