Add zizmor to pre-commit and fix potential cache-poisoning in wheels workflow

[hugovk]

Follow on from #8526.

Add zizmor to pre-commit, run the new version 0.10.0, and fix the one new thing it finds:

error[cache-poisoning]: runtime artifacts potentially vulnerable to a cache poisoning attack --> /Users/hugo/github/Pillow/.github/workflows/wheels.yml:3:1 | 3 | / on: 4 | | schedule: ... | 29 | | - "winbuild/fribidi.cmake" 30 | | workflow_dispatch: | |____________________^ generally used when publishing artifacts generated at runtime 31 | ... 263 | uses: actions/setup-python@v5 264 | / with: 265 | | python-version: "3.x" 266 | | cache: pip 267 | | cache-dependency-path: "Makefile" | |_________________________________________^ opt-in for caching here | = note: audit confidence → Low 54 findings (53 suppressed): 0 unknown, 0 informational, 0 low, 0 medium, 1 high 

More info: https://woodruffw.github.io/zizmor/audits/#cache-poisoning

In short, the idea is not to use caches in workflows that produce release artifacts.

This featured in the recent Ultralytics supply chain attack:

• https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/
• https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection

We don't run the wheels workflow that often, and the main time bottleneck is building and testing all the wheels, so it's not a big loss to download things from PyPI each time.

[radarhere]

The change is only for the sdist job, which is miles faster than any other wheel job, so I actually wouldn't consider it a speed loss at all.