Unify pip-compile flags for lockfile generation

[markuslf]

Context

pip-compile currently emits two warnings when regenerating
lockfiles/py3*/requirements.txt:

1. --strip-extras deprecation:

   --strip-extras is becoming the default in version 8.0.0. To silence
   this warning, either use --strip-extras to opt into the new default
   or use --no-strip-extras to retain the existing behavior.

2. Unpinned setuptools (combined with --generate-hashes):

   The following packages were not pinned, but pip requires them to be
   pinned when the requirements file includes hashes and the requirement
   is not satisfied by a package already installed. Consider using the
   --allow-unsafe flag.

Neither warning is release-blocking today, but pip-tools 8.0.0 will flip
the --strip-extras default, and the setuptools situation is only
papered over by build hosts that happen to have setuptools preinstalled.

Proposed change

Add --strip-extras and --allow-unsafe to every pip-compile
invocation in this repo:

• lockfiles/py39/requirements.txt
• lockfiles/py310/requirements.txt
• lockfiles/py311/requirements.txt
• lockfiles/py312/requirements.txt
• lockfiles/py313/requirements.txt
• lockfiles/py314/requirements.txt

The pre-commit lockfile (.github/pre-commit/requirements.txt) already
uses --strip-extras, only --allow-unsafe is missing there.

Rationale for --strip-extras (not --no-strip-extras): aligns with the
upcoming default and with the pre-commit lockfile, keeps the diff stable
when 8.0.0 lands.

Out of scope

Regenerating the lockfiles will refresh transitive hashes as a side
effect. That is expected and should land in the same PR as the flag
change.

Related

Tracked in parallel for sibling repos:

• Unify pip-compile flags for lockfile generation monitoring-plugins#1138