Consider new pinning startegies

[jku]

We are currently a bit stuck in worst of all worlds:

• We do work to maintain a requirements.txt already (see also Switch to uv for locked versions #1648) -- we also duplicate that work in https://github.com/sigstore/gh-action-sigstore-python/
• But our CLI users don't get any benefit of that work -- pip install sigstore is still supply chain roulette: you never know when a dependency has been popped
• our library users are still annoyed because we half-pin dependencies in pyproject.toml as well because not pinning at all will break CLI users sooner or later -- so the downstream library users can't upgrade e.g. cryptography on their schedule: they need to wait for sigstore-python to release first

Should we start releasing two packages?

• library that only limits direct dependencies known to be incompatible
• CLI that pins all direct and indirect dependencies

The counter arguments are

• This is likely a bit more work (since now we need to do CLI releases when dependencies get security updates). I also don't know how easy the the "workspace" approach to maintaining two packages in the same repo is in 2026...
• This does not strictly speaking prevent some indirect dependency from getting compromised, and us still pinning that compromised version