test: pin the .efw image header wire format (38 checks)

[srpatcha]

Closes items 1 and 2 of #66.

eos_image_header_t is the format eFirmware writes and eBoot parses. eos_image.h
pins four things about it — sizeof, and the offsets of hash, sig_type,
signature.

Those catch a field that grows, and a field inserted before hash. They do not
catch two same-width fields exchanging places. I compiled the header with
load_addr and entry_addr transposed:

all four existing static asserts: PASSED
load_addr  is now at offset 16 (was 12)
entry_addr is now at offset 12 (was 16)

A bootloader built from that header loads the image at its entry point and jumps
to its load address.

They also say nothing about the values of EOS_IMG_MAGIC, EOS_HASH_SIZE,
EOS_SIG_MAX_SIZE, EOS_IMG_SIGNED_LEN, or the five eos_sig_type_t
enumerators. All travel inside the image; all are wire format. Renumbering
EOS_SIG_ED25519 makes eBoot check an existing image's signature under a
different algorithm than the one that produced it — clean compile, green suite.

The change

tests/unit/test_image_abi.c — 38 checks: every field's offset and width
(either alone lets drift through — a field can keep its offset while changing
width, shifting everything after it), the total size, and the value of every
shared constant.

The numbers are restated here rather than shared with eFirmware deliberately.
Two independent statements of one contract, each in the repository it governs,
is what makes editing one side turn the other red. eFirmware#2 does the same on
its side.

Verified

Both drift classes the existing asserts miss:

transposed load_addr/entry_addr    36/38   names both offending fields
EOS_SIG_SHA256 renumbered to 9     37/38

restored                           38/38

ctest: 17/17, was 16/16.

Not in this PR

#66 item 3, found while measuring the above: eFirmware stamps
hdr_version = 1 into every image (efw_image.c:55), eBoot's
EOS_IMAGE_HDR_VERSION is 2. image_verify.c:89 accepts 1..2;
image_verify.c:202 then verifies over EOS_IMG_SIGNED_LEN with no branch on
version anywhere in the file — so a v1 image is admitted and then fails
signature verification, by eBoot's own documented definition of v1.

It fails closed, so this is not an escalation. Fixing it means choosing
between rejecting v1 at parse, branching the verifier, or restamping in efwtool
— a security-policy call. Left for a decision on #66 rather than folded in here.

Base

Branches from #58, which repairs the eos_crc32 conflicting-types build
failure on master. Merge #58 first.

Note this repo requires signed commits, which blocks this PR along with the
other nine — see #66 and the org-wide policy question.

[srpatcha]

Rebased onto #71, which namespaces every test target in this directory so eos
and eBoot can be composed into one CMake project. test_image_abi is now
eboot_test_image_abi; the add_test(NAME ...) label is unchanged, so ctest
output reads the same.

Worth recording that #71's configure-time guard caught this PR's own target
during the rebase, rather than the collision showing up later in a different
repository:

CMake Error at tests/CMakeLists.txt:128 (message):
  Test target 'test_image_abi' is not namespaced.  Name it
  'eboot_test_image_abi' so it cannot collide with a target of the same name
  in eos when ebuild builds both together.

That is the guard doing the job it was added for, on its first real
opportunity.

Re-verified after the rebase: 17/17 passed, 0 build errors.

Merge order is now #58, then #71, then this.