fixtures: put endianness in the id, not the arch directory

The fixture namespace is the arch-header set, but mips32el/ and mips64el/ were
in it and no such header exists — mips32.h serves mips and mipsel alike. Byte
order changes the captured bytes and the replay binary, not the layout model,
so it belongs in the id beside the variant.

Without it the two orders resolve to one directory and the capture rm -rf's the
destination first, so whichever cell ran last would be the one kept. That was
not hypothetical: ppc64/ already held a ppc64 and a ppc64le bundle, apart only
because their release strings happened to differ.

fixture_arch now maps mipsel to mips32 and mips64el to mips64, and the id
carries -eb/-el on the four arches that can hold both orders: arm32, ppc64,
mips32, mips64. The other nine are single-endianness, where a suffix would say
nothing. The value is read from the booted image's ELF EI_DATA byte — the
kernel's own statement of its byte order — rather than a table of which cell is
which.

Twenty existing bundles renamed, each suffix taken from its own uname_m_raw,
and mips32/mainline-7.0.0-eb regenerated to confirm a capture lands beside its
LE sibling instead of replacing it. Binary selection was never at risk:
validate-bundle resolves it from uname_m_raw, which is endianness-aware and
untouched.

validate-fixtures 27 sound / 0 FAIL, replay 58 pass.

Author: bcoles