Fix TestPyPi storage quota

[titusfortner]

Note: I've requested a new selenium organization on pypi and test.pypi to make
account management easier because the TLC does not currently have access to test.pypi.

The selenium project on TestPyPI has reached its 10 GiB project storage
limit, so every nightly upload is rejected with 400 Bad Request. The Python
nightly release job has failed every night since 2026-08-12.

Note that Production PyPI is well below its limit.

Index	Files	Total size	Percent of 10 GiB limit
PyPI (production)	342	1.04 GiB	10.4%
TestPyPI	1839	9.995 GiB	100%

We cannot fix this with automated pruning from the CI since PyPI API
tokens are upload-only and Warehouse exposes no deletion API at all
(pypi/warehouse#11397), so deletion happens only through the authenticated web
interface.

Option 1: Request a larger quota

Submit a project size limit increase request for selenium on TestPyPI. This
is non-destructive and should be attempted first, though it may be declined
since TestPyPI is documented as a scratch index whose contents may be pruned
without notice.

Option 2: Delete old nightlies

Manual deletion through the form will be too cumbersome, so some form of script
will need to be executed locally (not on CI) to manage this.
Since there is no deletion API, every scripted
approach reduces to submitting the same per-release web form (csrf_token and
confirm_delete_version) against an authenticated session.
There is an existing third-party tool pypi-cleanup
that does this with pattern matching and age filter, but it authenticates by scraping the web
login form and takes the account password directly,
so it should be run with great care and never on production.

Consideration for what to retain:

Retention	Releases deleted	Reclaimed	Remaining	Runway
30 days	890	9.71 GiB	0.28 GiB	~950 nights
90 days	827	9.09 GiB	0.91 GiB	~885 nights

Notes:

• Packages must be deleted not just yanked to reclaim quota
• Nightlies are reproducible from previous commits, so any deleted
  version can be rebuilt from its commit if it is ever needed for local review.

Future consideration

Since Selenium Manager binaries make up 90% of the size of packages, it might make
sense to release those in separate packages. Especially since #17586
plans to add two more aarch64 binaries to releases.

Publishing a pure-Python selenium wheel plus architecture-tagged Selenium
Manager wheels (previously raised in #13021) would likely solve this issue indefinitely and prevent
a potential future issue on production.

[diemol]

FYI, I deleted older releases than 8 days "manually" using the package mentioned in option 2.

[kitaijerriann26]

Since the manual deletion of old nightlies is cumbersome, we could create a script that automates the submission of the web form for deleting versions, ensuring it handles the csrf_token and confirm_delete_version parameters correctly. Additionally, if we do decide to go with Option 1, we should prepare a well-documented request for the larger quota that explicitly outlines our usage patterns and the project's growth to improve our chances of approval.