nixpkgs-multiverse: every version that ever existed

The core change is the elimination of manual pinning. Previously, engineers had to add a new Nixpkgs input for every distinct package version they needed, bloating the flake and triggering eager fetches of unused inputs. nixpkgs-multiverse collapses all 1,393 revisions into one input, so only the specific revision referenced is fetched. This shifts the cost from per-flake overhead to a one-time metadata download that is amortized across all future builds.

Access patterns become simpler and more expressive. Instead of hunting for a commit hash or release tag, engineers can query versions directly (`python3."3.6.2"`) or ask for the latest (`latest.python3`). The flake exposes a uniform interface for every package ever shipped, regardless of whether it was in a stable release or an unstable channel bump. This uniformity stops working if the package was never built by Hydra, but the index is limited to commits that were actually cached, so failures are rare.

The implementation relies on two JSON files: `revisions.json` (an ordered list of every cached commit) and `versions.json` (a mapping of package names to version strings). These files are generated from the nix-releases S3 bucket, which records every Hydra build. The flake itself has no inputs; it uses `builtins.fetchTree` with a `narHash` to fetch only the needed revision. This design means the flake is self-contained but depends on the S3 bucket remaining available and accurate.

Mixing multiple versions in a single environment is now trivial. Because Nix isolates dependencies via hashes, different Python versions can coexist in the same shell or package closure. The flake exposes each revision as a distinct attribute set, so engineers can combine packages from different points in time without conflict. The limitation is that the flake only knows about revisions that were built and cached, so very old or very new packages may be missing if Hydra never processed them.