blacklist the __pypy__ helpers that attack the fuzzer instead of the target

[devdanzin]

Follow-up to #256, caught while validating the first PyPy 3.11 fleet config.

Five members of __pypy__ are debug/test plumbing rather than fuzzable surface, and each
manufactures a crash that never happened:

member	what it does	why it must go
attach_gdb	"Run an interp-level gdb"	runs gdb inside the session; its banner (For bug reporting instructions...) hits the bug word. Observed live as __pypy__-bug-systemerror.
_internal_crash	"for testing purposes, raise an interpreter-level ValueError. Should turn into a SystemError automatically"	SystemError is a 1.0 crash word — with --test-private this alone tagged 4 of 4 __pypy__ sessions as crashes
remote_exec	"Executes a script of Python code in a given remote Python process"	fuzzer-chosen pid ⇒ arbitrary code injection into any process on the box, incl. sibling fleet instances and the fuzzer itself
set_code_callback	process-global hook on every code-object creation	hand it a fusil bomb object and the rest of the session detonates on unrelated code
pyos_inputhook, revdb_stop	PyOS_InputHook() / reverse-debugger stop	block

This is the "generated code kills its own session" class from #192, plus one genuine host
hazard (remote_exec).

Deliberately narrow. __pypy__ is PyPy-only surface with no CPython counterpart —
the reason to fuzz PyPy at all — so newdict / strategy / internal_repr / intop /
move_to_end and the rest stay fuzzable. test_pypy_blacklist_stays_narrow pins that
direction so a future edit can't quietly blanket the module.

Verification

PyPy 3.11.15 / 7.3.23, --test-private --functions-number 60:

• before: 4/4 sessions tagged __pypy__-systemerror
• after: 5/5 clean, zero calls to any blacklisted member, 3.3k–4.9k lines of real
  fuzzing per session

Full suite green (1249 tests); ruff check + ruff format --check clean.

🤖 Generated with Claude Code