The big-endian family is narrower here than in libcompact

This library exports two big-endian codecs, uint32be and uint64be. libcompact exports eight: uint16be, uint32be, uint64be, uintbe, int16be, int32be, int64be and intbe.

So six codecs exist in the C implementation with no counterpart here: uint16be, uintbe, int16be, int32be, int64be, intbe.

The practical consequence is that those six cannot be checked against this library at all. We are building a cross-language conformance corpus whose byte vectors are generated from this implementation as the reference, which means a codec this library does not have has no canonical bytes to check anything against - so the C big-endian family is the one part of its surface a conformance run can never cover. It stays that way until either side moves.

Three ways that could go, and we have no stake in which:

1. This library gains the six, and they become checkable like everything else.
2. libcompact drops them, if nothing depends on them.
3. They are deliberately C-only, in which case saying so is enough - we would record them as out of scope with that reason rather than as a gap nobody got to.

Worth noting the same asymmetry reaches further: int16be, int32be and int64be are signed big-endian, and this library has no signed big-endian codec of any width.

Start by inspecting the existing uint32be and uint64be codecs, then compare them with libcompact's six additional big-endian codecs: uint16be, uintbe, int16be, int32be, int64be and intbe. First establish whether this library should add them, libcompact should remove them, or the codecs should be recorded as deliberately C-only; done means the chosen direction is explicit and the conformance gap has a corresponding outcome.