drop ppc64: its artefacts cannot load where they ship

[talaria0101]

Drops ppc64, meaning PowerPC 64 big-endian. ppc64le is ELFv2 and is
untouched.

Why

That architecture is split across two incompatible ABIs and an ELF object is
one or the other. Debian's powerpc64-linux-gnu toolchain targets ELFv1.
Measured on debian:bullseye-slim and on debian:trixie-slim:

powerpc64-linux-gnu-gcc   defines _CALL_ELF 1
sysroot loader            ld64.so.1
-mabi=elfv2               ld: ABI version 2 is not compatible with
                          ABI version 1 output

So every ppc64 artefact this project has published carries ELFv1. On the
v0.2.3 assets:

ppc64-cross-libc-dlopen.so    abiv1  DT_NEEDED ld64.so.1
                              GLIBC_2.3 2.3.3 2.4 2.6 2.16 2.22
ppc64le-cross-libc-dlopen.so  abiv2  DT_NEEDED ld64.so.2
                              GLIBC_2.17 2.22

The AppImage runtimes that would carry it are ELFv2 throughout, loader, libc
and application binary. Their loader refuses the object on a path that exists:

ERROR: ld.so: object 'cross-libc-dlopen.so' from --preload cannot be
preloaded (cannot open shared object file): ignored.

A process is one ABI from its loader up. An ELFv2 application cannot dlopen
an ELFv1 host driver whatever this project ships, and an ELFv1 one cannot load
an ELFv2 preload. The gap is not closable here, so the target goes rather than
shipping an artefact that can never load and prints an error on every launch.

Measured after the removal

scripts/build.sh --arch ppc64      exit 1, names the remaining targets
scripts/build.sh --arch ppc64le    builds, every artefact check passes,
  --engine podman                  floor glibc 2.31
scripts/check-charset.sh           exit 0, 140 files
scripts/check-drift.sh             exit 0, all sections
scripts/verify-gates.sh            exit 0, 14 gates proven, 0 not

The two review passes

Pass 1. What did this change stop measuring? Scope: every list that
enumerates architectures and every check that loops over one. Falsifier: it
finds nothing only if every such list now agrees and no check lost coverage
silently.

Swept grep -rnIE 'x86_64[ ,|].*aarch64|GLFWD_CROSS|arches=|arch: \[' across
scripts, workflows, Makefile and docs. Found four stale counts, all in
release.yml and all spelled as words, so grepping for ppc64 could never
reach them: "the four cross-compiled architectures", "a six-architecture", "the
four newer targets", "six architectures arrive". Corrected in the second
commit.

Pass 2. What does this removal break that nothing in the tree covers?
Scope: consumers of the removed path, code reachable only from it, and anything
asserting an asset set. Falsifier: it finds nothing only if no tracked file
still reaches for a ppc64 artefact, a ppc64 toolchain or the ELFv1 trampoline.

Swept every remaining ppc64 that is not ppc64le or ppc64el. Found the
readelf-over-nm rationale in src/Makefile and scripts/verify-artifacts.sh
citing a correct ppc64 build as its reason. That build is no longer produced.
Both now record the measurement in the past tense and say the form is kept
because it counts on every target. The pass also caught that my first commit
had generalised the Makefile copy to "a PowerPC build", which dropped the
ELFv1 .opd detail that is the whole reason nm was wrong.

Two things named rather than changed

⛔ src/gl-fwd.c's ELFv1 trampoline stays. It is guarded by
#elif defined(__powerpc64__), the fallback below
#elif defined(__powerpc64__) && _CALL_ELF == 2, so it is unreachable from
this build matrix but still the correct path for anyone compiling natively on
an ELFv1 PowerPC host. Deleting it is a change to src/, which
docs/conventions/code.md says owes a case that fails before and passes after,
and a removal cannot have one. Happy to do it in its own pull request if you
would rather it went.

⚠ docs/todo/PROGRESS.md is not rewritten. Its line about v0.2.3 shipping
66 assets across six architectures is still true of that release, and its work
order belongs to the in-flight drop-portable-variant branch. Reconciling it
is the close-out of whoever owns that branch, not this pull request's to
clobber.

One rule this bends, with permission

docs/conventions/git.md section 4 forbids forking, and section 2 expects a
branch on this repository. talaria0101 has pull only here, so the branch is
on a fork. Samueru asked for this pull request and granted it as a code owner
in the thread linked below. Flagging it so the next reader of git.md does not
think the rule moved.

---

Requested by Samueru via errand.
Conversation: https://discord.com/channels/1313385177703256064/1547664011632578691
Transcript: https://talaria.qaidvoid.dev/?session=6a82hff