…byte order for float16

The slow-path decoder for IEEE_754_FLOAT16_LE/BE computed the
byte-order flag by comparing mformat_code against IEEE_754_FLOAT_LE
(the 32-bit float constant) instead of IEEE_754_FLOAT16_LE. Since the
float16 mformat codes are never equal to that constant, the comparison
was always false, so the decoder always treated input as big-endian
regardless of what was requested.

Adds a regression test. A real 'e'-typecode array only exercises the
slow/converting path when the requested mformat disagrees with the
machine's native float16 format, so which direction (LE/BE) exercises
the buggy branch depends on the test machine's endianness, and the
other direction happens to come out "correct" by coincidence since the
bug unconditionally decodes as big-endian. The test uses a typecode
('d') whose native format can never match the float16 codes, forcing
the slow path deterministically on any machine.

…ction

array._array_reconstructor is internal/private and has no Sphinx docs
entry, so the :func: cross-reference role can't resolve and trips the
docs CI's new-NEWS-nit check.