Fix security issues with the Trusted Publishing example

https://github.com/simonw/python-lib/blob/4b825ed/%7B%7Bcookiecutter.hyphenated%7D%7D/.github/workflows/publish.yml#L44-L49 suggests that building the dists within the same job that publishes them is okay. But it's not.
Such a structure opens the workflow users to privilege escalation through poisoning the build dependencies, which is why I've always insisted on the separation — the build scripts must never have access to id-token: write.

• https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
• https://docs.pypi.org/trusted-publishers/security-model/

Another suggestion is to fix the GitHub Environment name to represent the deployment target as it's meant to. I usually go for pypi and testpypi so it's obvious that uploading to both is separate.

I saw release here https://github.com/simonw/python-lib/blob/4b825ed/%7B%7Bcookiecutter.hyphenated%7D%7D/.github/workflows/publish.yml#L33C5-L33C25, which is not an upload target but a process name which is very generic.

The declaration syntax can also be extended to include a URL:

-     environment: release
+     environment:
+       name: pypi
+       url: https://pypi.org/project/{% endraw %}{{ cookiecutter.hyphenated }}{% raw %}/${{ github.ref_name }}

Beginne mit {{cookiecutter.hyphenated}}/.github/workflows/publish.yml, insbesondere mit den Zeilen 33 und 44-49, und lies anschließend die verlinkten PyPI Trusted Publishing-Richtlinien. Prüfe, wie die Build- und Publish-Schritte Berechtigungen gemeinsam verwenden und wie die Release-Umgebung benannt ist. Die Aufgabe ist erledigt, wenn der Workflow das Erstellen vom Veröffentlichen trennt, den Zugriff auf id-token von Build-Skripten fernhält und die PyPI-Ziele mit ihrer Projekt-URL benennt.