Separate resolution and download concerns in resolver providers #1257

Description
The runtime resolver providers (PyPIProvider, GitHubTagProvider, GitLabTagProvider) conflate two responsibilities: finding which versions exist and deciding where to download from.

The override_download_url parameter leaks download concerns into the resolver, and the Candidate.url field is overloaded to carry the download location through from resolution to download.

Current behavior
The config-layer resolver classes (e.g. PyPIGitResolver) pass download-related information like override_download_url to the runtime resolver. The resolver stamps this URL onto Candidate.url during version resolution (see _find_candidates() in resolver.py). The download() method then blindly reads candidate.url with no logic of its own.

This means:

• The resolver decides where to download from, not just which versions exist
• Candidate.url means different things depending on the provider (PyPI sdist URL, git+https://... VCS URL, GitHub API tarball URL)
• The download() methods on the config-layer classes are trivial one-liners because the resolver already did the download-related work
• Adding a new download strategy requires modifying the resolver, even if resolution logic doesn't change

Expected behavior
Resolution and download should have clear boundaries:

• Resolver returns version candidates (name, version, upload_time, remote_tag, etc.) but not the download URL
• Downloader constructs the download URL from its own config and the resolved version
• Candidate is not overloaded as a URL carrier between the two phases

Context
The current design is historical, override_download_url existed on the runtime providers before the new source config layer (_resolver.py) was built. The config layer was designed to reuse the existing runtime providers but it carries the coupling forward.