5: Add 2.x related warnings r=ltratt a=nanjekyejoannah

I have broken away the warning bit from the [flag](python#3 ) and the [port ](python#4 )PR. Well, the way function calls are done between C and Python is confusing, nothing scary anyway, review maybe a bit annoying.

Review this PR before python#4 

Co-authored-by: Joannah Nanjekye <jnanjekye@python.org>

7: Port cmp with no extra slot r=ltratt a=nanjekyejoannah

Due to segfaults introducing a new `tp_compare` slot proved problematic. I have found a way of supporting `cmp` without a new slot. Tests are updated to match the new functionality where Py2.x doesn't fail.

I wanted to force push on [this branch] (https://github.com/softdevteam/pygrate3) but maybe you wanted to compare before I force push.

This replaces python#4 



Co-authored-by: Joannah Nanjekye <jnanjekye@python.org>

Pushes 36, 37, 38 all gated against the stale python_gate from
push 33 (8382896), not their respective HEAD binaries.

Root cause: 'cp "$PYTHON" "${PYTHON}_gate" 2>/dev/null || true'.
When a prior gate left python_gate held open (or otherwise busy),
cp failed with 'Text file busy', stderr was discarded, '|| true'
swallowed the exit code, and PYTHON pointed to the leftover stale
copy. Subsequent test runs reported 981 PASS — against a binary
from 3 commits ago.

Fix: rm -f the destination first, then cp without || true. If cp
fails for any reason, set -e aborts the gate. No more silent
fallback to a stale binary.

Discovery: testkeeper investigated SIGSEGV during G1.6 LIR-capture
prep on the actual HEAD binary (carrying generalist's in-flight
LOAD_ATTR_SLOT stash). The crash didn't reproduce on python_gate
because python_gate was 3 commits old and predated the SLOT work.
The version-string mismatch ('79890e7b73-dirty' vs '8382896c85')
made the stale-binary substitution visible.

Also adds catch python#4 to docs/wiring_catches.md per supervisor
2026-04-22 00:42:38Z directive.

…ation)

Push 39's e808676 + 0a5f096 added BINARY_MATCH on both arches.
The grep is bare-hash: 'grep "$COMMIT_HASH" "$LONG_VERSION"'. That
matches both clean ':<hash>,' AND '-dirty:<hash>' suffix — the
exact contamination class that bit catch python#4 (binary built from a
dirty working tree masquerades as a clean build).

Pre-push-39, 'cp || true' accidentally protected against this by
falling back to a stale-clean python_gate when local build was
dirty. Push 39 removed the fallback. Without -dirty rejection,
the next contaminated build IS the binary the gate tests, while
BINARY_MATCH still passes.

Fix: tighten the check to reject any version string containing
'-dirty'. Mirror on ARM64 path (mirrors 0a5f096 symmetry).
Output now distinguishes BINARY_MISMATCH (wrong hash) from
BINARY_DIRTY (right hash, dirty build).

Adds catches python#5 (push-39 in-flight commit race) and python#6 (this
fix) to docs/wiring_catches.md.

Per supervisor 2026-04-22 01:08:18Z + theologian 01:08:00Z
(defense-in-depth: when a single incident exposes N adjacent
gaps, fixing 1 leaves N-1 unprotected).

Per supervisor 2026-04-22 03:06:55Z + theologian 03:07:12Z + pythia python#58:
push 44 introduces the W3 R4 oracle dispatcher in compiler.cpp behind
#ifdef RC_ORACLE. The push-44 nm production-binary check is one-shot —
need a STANDING gate assertion so future compiler.cpp edits cannot
silently leak RC_ORACLE dispatch into production.

Failure mode caught:
  Any future commit that drops, inverts, or accidentally hard-defines
  the #ifdef RC_ORACLE guard would leak the C++ rc_oracle dispatch path
  (linked from libphoenix_rc_oracle.a) into the production python
  binary. Without this assertion, the leak is invisible until the next
  manual nm audit. Same silent-failure class as the cp-||-true loophole
  (catch python#4, push 38) — accepted bad state silently.

Implementation (5 LOC after BINARY_MATCH (clean) ✓):
  RC_ORACLE_LEAK=$(nm $PYTHON | grep -c 'rc_oracle')
  if [ $RC_ORACLE_LEAK -ne 0 ]; then
      echo BINARY_RC_ORACLE_LEAK_DETECTED ...
      exit 1
  fi
  echo BINARY_RC_ORACLE_OK: production binary clean (0 rc_oracle symbols)

Verbatim wording per gatekeeper item python#15 (03:07:25Z):
  - PASS: 'BINARY_RC_ORACLE_OK: production binary clean (0 rc_oracle symbols)'
  - FAIL: 'BINARY_RC_ORACLE_LEAK_DETECTED' + FATAL + exit 1
  - Mirrors BINARY_DIRTY discipline (catch silent failure structurally)

Verification (compile-clean pre-commit):
  bash -n scripts/gate_phoenix.sh: SYNTAX OK
  Inserted at line 120 (immediately after BINARY_MATCH block at line 119).

Bundled into push 44 (rather than standalone push 45) because the
dispatcher lands in this push — the leak-check guards it from day 1
instead of leaving a one-push window where item python#15 isn't enforced.

Push 44 batch grows 3 → 4 commits:
  THIS COMMIT  — gate item python#15 (RC_ORACLE leak assertion)
  63568c0   — W3 Step 5 expansion (4 injection classes + invariant python#7)
  4f591a1   — W3 Step 5 v1 (rc_oracle_self_test.sh)
  a99db92   — W3 Steps 1-4 (scratch lib + dispatcher)

ABBA cap usage: 17 → 18 (4 commits this push).