[Homebrew/Python] Build CPython and its standard library inside the core tap

[brandonpayton]

Why

Python still depends on Kandelo's legacy package registry for its source
build. That prevents the core tap from owning the complete recipe and
blocks retirement of the registry entry.

Cross-compiling CPython also requires a native Python from the same
major/minor release. That interpreter must be a declared, sealed build
input. An ambient host Python would make the bottle depend on whichever
tool happened to be installed on the CI runner.

What changed

• Build the target CPython 3.13.3 interpreter from the Formula's
  checksum-verified upstream source.
• Declare Homebrew python@3.13 as the native build interpreter, using
  CPython's supported --with-build-python contract.
• Require that interpreter to resolve inside the declared
  Cellar/python@3.13/<version> keg, be read-only, and report version
  3.13.
• Link the target interpreter against the core tap's zlib Formula.
• Instrument and validate the interpreter for Kandelo's fork and ABI
  contracts.
• Package the standard library deterministically beside python,
  python3, and python3.13.
• Exercise the installed interpreter, standard library, and zlib in
  both Node and Chromium.

Python remains wasm32-only. This change does not add a language-specific
VFS image; lazy image composition can select the Python bottle.

Closed build boundary

The Kandelo runner seals the native Homebrew keg and its complete
dependency closure before the recipe starts. The recipe then verifies
that python3.13 did not fall back to /usr or another ambient path.

The runner also supplies target configuration and fork instrumentation
from the exact Kandelo revision chosen by the publisher. Formula or
recipe code cannot substitute a checkout or a different tool.

The recipe copies the read-only sysroot into private working storage and
opens only that copy before adding CPython's required WASI emulation
archives.

Inline WHY comments preserve these non-obvious authority and
reproducibility decisions.

Validation

• The Python migration contract passes.
• brew style Formula/python.rb reports no offenses.
• Ruby and shell syntax checks pass.
• ShellCheck reports no error-level findings.
• git diff --check passes.
• Formula support passes 128 tests and 2,285 assertions.
• Publisher trust checks pass.
• All 19 trust-rotation tests pass.

Dry-run investigation established three separate packaging boundaries:

1. A Homebrew LLVM keg contained a link outside its sealed closure.
2. The private sysroot copy retained the source's read-only mode.
3. Using target LLVM as a native compiler selected an unavailable host
   loader.

The recipe now uses the declared native python@3.13 dependency instead
of attempting that invalid compiler bootstrap. The first attempt of dry
run 30469839479, on runner image 20260726.254.1, rejected the
runner's unconditional /usr projection before the recipe started.
That is runner-instance evidence, not a stable runner contract; this PR
does not weaken the rejection or expose more host state.

The exact retry and exact-head control 30471174839, both on runner
image 20260720.247.2, crossed that boundary. The control installed the
declared Cellar/python@3.13/3.13.14_1 keg, passed the keg-path
assertion, and built the target bottle: 750 files and 28 MB in 3 minutes
39 seconds.

Both builds then reached the shared Formula runtime and failed before
Python executed because programs/dash.wasm had no matching selected
package projection. They used Kandelo commit 85d2efc, which predates
the central resolver fix in Automattic/kandelo#1136. Further expensive
retries are parked until Automattic/kandelo#1138 lands and the tap
rotates trust to its new exact publisher commits.

The existing bottle block remains last-green evidence until an exact
protected build replaces it. This draft must still pass the live Node
and Chromium Formula lifecycle before merge.