Fix: Remove redundant PyPI fetch causing CDN cache failures

[arvarik]

Summary

Fixes the remaining PyPI race condition where the second script step was hitting a stale Fastly CDN cache node.

Deep Dive into the Failure

Even after the previous fix, the 1.1.7 pipeline failed. Here is why:

1. The Wait Loop: curl requests PyPI. Initially, it hits cache misses and gets 404s. Once PyPI publishes the package, it hits a cache node, gets a 200 OK, writes the valid JSON to pypi.json, verifies the sdist is present, and successfully exits the loop.
2. The Download Step: The very next step immediately fired another curl request to PyPI for the exact same URL.
3. The CDN Cache Race: PyPI is fronted by Fastly (a global CDN with many edge nodes). Because the second request was made milliseconds later, it hit a different Fastly edge node that had not yet synchronized the cache. It returned the stale 404 response!
4. The Crash: Because it returned 404, curl -sf silently failed and overwrote pypi.json to be empty. The Python script then crashed trying to parse the empty JSON.

The Fix

Since the Wait loop successfully verifies and writes the valid JSON to pypi.json, there is no reason to fetch it again. Both steps share the same GitHub Actions workspace disk. By removing the redundant curl fetch from the second step, it will securely re-use the pypi.json file that was already guaranteed to contain the sdist.

This guarantees 100% deterministic CI behavior regardless of PyPI cache propagation.