Require wheels when installing the Python dependencies used by the build
tooling, with a named exception for the local `python-build-standalone`
package. This avoids implicit third-party source builds without changing
the interpreter builds performed by the project. Pin the isolated build
dependencies for the source-build exceptions, including their transitive
build requirements.

---------

Co-authored-by: zaniebot <242828183+zaniebot@users.noreply.github.com>

## Summary

Use `gh pr merge --squash --admin` when merging the versions bot's
release-manifest PR. The `versions` ruleset requires human review but
grants `astral-versions-bot` a pull-request-only bypass. Plain `gh pr
merge` stops at its blocked-PR preflight check instead of attempting the
merge with that permission.

This completes the workflow-side change for
astral-sh/github-policies#31 and
astral-sh/github-policies#34. The failure was
observed in astral-sh/versions#163 ([release
job](https://github.com/astral-sh/ty/actions/runs/32198672332/job/95944618373)).

Switch CPython 3.12+ builds to the upstream Setup.stdlib
extension-building mechanism while preserving the existing static/shared
linkage behavior.

* Build pkgconf on macOS so that bundled dependencies can be discovered
and configured.
* Generate a minimal Setup.local for shared and disabled overrides on
CPython 3.12+.
* Restore CPython’s post-build extension checks and remove obsolete
patches/workarounds.
* Preserve SQLite extension loading and macOS symbol hiding.
* Explicitly disable the clinic test and `xxlimited_3_13` extensions.
c.f. #1185

With this change, `extension-modules.yml` is still used for the
following in CPython 3.12:
* Disabling modules
* Specifying static vs shared linkage
* Validating the extension modules specified in the CPython source
archive.
* Constructing `PYTHON.json`

Constructing `PYTHON.json` for CPython 3.12+ from other sources is a
needed follow up.

Makes various patches unnecessary:
* closes #869 
* closes #875 (This patch is only applied on Python 3.11)
* closes #876 (this patch is only applied on Python 3.11)

Configuration can now appropriately detect SIMD support in the toolchain
and adjusts `libhacl` flags accordingly.
* closes #883
* closes #645
  
This does not add shared extension suggested in #227. This could be done
with a small change as a follow up.

The `_testclinic` module introduced in 3.12.0 was backported to 3.10
(python/cpython@3144aca)
and 3.11
(python/cpython@dd323af).

Disable the module on all Python versions as it is only needed for
testing.

closes #1222

* libffi 3.4.6 -> 3.4.8

Remove the inline patches which have been merged upstream.

Use the same libffi version for musl builds by patching libffi so that
PATH_MAX is provided by the libc limits.h rather than the Linux kernel
linux/limits.h.

Remove the unused libffi-3.3 package.
closes #814

Add a document (`BENCHMARKS.md`) which discusses the performance on
python-build-standalone in pyperformance benchmarks compared to other
CPython distributions.

---------

Co-authored-by: Brent Westbrook <36778786+ntBre@users.noreply.github.com>

Linux distributions built here carry no `.note.gnu.build-id`. That makes
them
invisible to debuginfod: the protocol is keyed entirely on that ID, so a
debugger
reading one of these binaries has nothing to ask with, and no symbol
server —
yours or anyone else's — ever receives a request. This adds
`-Wl,--build-id=sha1` to `target_ldflags` for the Linux targets. Refs
#522.

`sha1` rather than `uuid`: it is derived from the linked content, so it
does not
affect build reproducibility.

## What I measured

`.note.gnu.build-id` in `install_only_stripped` artifacts:

| release | target | build ID |
|---|---|---|
| 20250205 (3.12.9) | aarch64 | present —
`54c37326ccd9e6e2e10a1c0857b5977aecfdc103` |
| 20250612, 20250626, **20250630** | aarch64 | present |
| **20250702**, 20250807, 20250828, 20251010 | aarch64 | absent |
| 20260814 (3.13.15) | aarch64 | absent |
| 20250630, 20250702 (3.12.11) | x86_64 | absent |
| 20260814 (3.10.21 / 3.12.14 / 3.13.15) | x86_64 | absent |

Two separate things, worth separating:

- **x86_64 never had build IDs**, on either side of that window.
- **aarch64 lost them between 20250630 and 20250702**, which lines up
with
21cf744 ("Enable native builds on Linux aarch64"). Before it, aarch64
was
cross-compiled with a host toolchain; afterwards it uses the in-tree
one, as
  x86_64 always did.

Co-authored-by: Claude <noreply@anthropic.com>