ERROR: Could not find a version that satisfies the requirement when migrating indexes with overlapping package names

Context

During a zero-downtime migration from a legacy PyPI index to a new private index, the same package names exist in both sources. Pip's resolver does not guarantee priority between --index-url and --extra-index-url, and PEP 708 repository metadata is not yet enforced by tooling.

Problem

When the new index lacks a package version that the old index provides, the resolver may emit ERROR: Could not find a version that satisfies the requirement even though the package exists in the aggregate. This error appears intermittently during rolling deployments because the resolver's index selection is non-deterministic across pip versions 20.3 through 24.x.

Constraints

• Pre-mirroring all dependencies with --no-index and --find-links breaks zero-downtime for dynamic dependency graphs.
• Bandersnatch does not rewrite metadata to include PEP 708 Repository fields, so mirrored indexes cannot enforce source-based resolution.
• Authentication tokens for private indexes may leak via --extra-index-url in logs.

Questions

1. What combination of pip flags and index configuration yields deterministic resolution during a cutover without pre-mirroring?
2. Can PEP 708 metadata be injected post-mirroring to enforce source priority, and which tooling versions support it?
3. How should a rolling deployment sequence be structured to avoid the version-satisfaction error when indexes are switched incrementally?