feat(MeshIO): binary PLY write and byte-order-correct read (#25)

[csparker247]

What this is

PLY binary write support, plus the endianness fix on read. Tracks #25.

This PR started as the docs-only feature plan; the branch now carries the
full implementation of all 5 phases / 22 tasks. Depends on #24 (merged as
2eaba49). Precedes #19.

What changed

Area	Change
Read	read_ply now honors the byte order declared in the header instead of reinterpreting raw bytes as native. The binary_big_endian rejection is gone.
Write	New public PLYFormat { ASCII, Binary } on all three write_ply tiers, defaulting to ASCII. Binary writes native order and labels the header to match.
Validation	write_ply rejects faces whose uchar list counts cannot be expressed: 255 corners for vertex_indices, 127 with UVs since texcoord writes 2*N.
Docs	@throws and PLYFormat on the write_ply overloads and the write_mesh dispatchers.

write_ply(path, mesh);                        // unchanged — ASCII
write_ply(path, mesh, PLYFormat::Binary);     // new
write_ply(path, mesh, uvmap, PLYFormat::Binary);
write_ply(path, mesh, uvmap, tex, PLYFormat::Binary);

Read before write, as the plan ordered it: the reader held the existing bug, is
the smaller change, and is the only instrument that can check the writer.
Phases 1–2 are the standalone correctness fix; 3–5 add the feature.

Behavior changes to know about

• Windows ASCII callers stop getting CRLF. All three tiers now open with
  std::ios::binary unconditionally. On POSIX this is a no-op — ASCII output is
  byte-identical to the pre-track writer across all three tiers, verified by
  compiling the same generator against e9635ab's header and diffing. Nothing
  regresses on read: read_ply already trims \r
  (PLYTest.ReadCommentTextureFile_CRLFLineEndings).
• binary_little_endian previously meant "native, labeled little-endian".
  On the little-endian hosts EduceLab runs on this was invisible, so no existing
  file changes meaning — it was still wrong.

detail signature changes — #19 will need to rebase

Both tracks rewrite write_ply_header and write_ply_data.

Function	Change
write_ply_header	trailing PLYFormat format
write_ply_data	trailing PLYFormat format; delegates to new write_ply_data_binary
read_ply_binary_prop	trailing bool needs_swap — no default, by design
read_ply_prop_from_buf	trailing bool needs_swap — no default, by design
read_ply_face_binary	bool needs_swap after load_texcoords
kMaxFaceVertices, kMaxFaceListLength	moved from function-local constexpr in two functions to namespace scope in detail

Omitting the default on needs_swap was deliberate: it made the compiler
enumerate all fifteen call sites rather than letting one silently misread a
property.

Testing

TestMeshIO goes from 82 to 100 tests. Green in Debug and Release; Doxygen at
the pre-track warning count (22, unchanged, zero new).

Round-trips deliberately do not anchor this work — a byte-order mistake
shared by reader and writer round-trips perfectly, which is how the sized-alias
bug in #24 survived. Instead:

• Reader: hand-crafted binary_big_endian fixtures with bytes reversed by
  the test itself, covering every scalar width the format uses (float, double,
  ushort, uchar count, int32 list). Values are non-palindromic so an unswapped
  read cannot pass by accident.
• Swap-before-cast gets its own test at each choke point — BE 3F 80 00 00
  must read as 1.0, not the denormal 4.6e-41.
• Writer: byte-level assertions against hand-derived IEEE-754 literals, so
  the tests encode the format rather than libcore's opinion of it. A Mesh3d
  write is asserted byte-identical to the Mesh3f one.
• Round-trips only for structural breadth: n-gons, UVs, colors, normals,
  empty mesh, and the maximal legal faces.

Two findings worth flagging:

1. PLYTest.BinaryBigEndian_Throws was passing for the wrong reason — its
   fixture declares a face but writes no face bytes, so after the rejection was
   removed it threw on truncation instead. It would have stayed green whatever
   the byte-order code did. Replaced with a positive read test.
2. Task 3.3's "verify, do not assume" became a static_assert: the writer's
   limits are now checked against the reader's caps at compile time, so raising
   either without revisiting the other is a build error rather than a file
   libcore writes and refuses to read.

Manual verification

Verified in MeshLab 2025.07 against a matrix varying only face arity and the
presence of a texcoord list:

Mesh	ASCII	Binary
triangles, no texcoord	loads	loads
triangles + texcoord	loads	loads
quad, no texcoord	loads	loads
quad + texcoord	fails	fails

Binary loads wherever ASCII loads and fails only where ASCII already failed, so
the binary writer introduces no incompatibility.

The quad + texcoord row is a MeshLab constraint, not a libcore one:
texcoord is a list property and a 2*N count on an N-corner face is what the
format allows. MeshLab's bundled libio_base.so carries vcglib's
import_ply.h error table including "Face with no 6 texture coordinates" —
per-wedge texcoord is hard-coded to 6 floats, so vcglib's polygonal path is
unavailable once texcoords are present. Those files parse correctly against an
independently written PLY reader and round-trip through read_ply, and the
failing ASCII file is byte-identical to what e9635ab wrote. Recorded as an
interoperability note in spec.md; nothing to change here.

Out of scope

• A format parameter on write_mesh — a PLY-only value is meaningless for half
  its inputs. Deferred to write_mesh: options struct for backend-specific behavior #26; write_mesh gains only @throws docs.
• Writing non-native byte order; widening list counts beyond uchar;
  configurable scalar width. See spec.md for the rationale on each.