Fix heap-buffer-overflow in _ctmStreamReadSTRING and stop parsing on string read errors

[Fedr]

Summary

Fixes a heap-buffer-overflow write reachable from the public ctmLoad() on a single crafted .ctm file (CWE-190 → CWE-787), reported privately by Kamal Sentassi of S9S Security Research under coordinated disclosure.

_ctmStreamReadSTRING() read a 32-bit length and called malloc(len + 1). For len = 0xFFFFFFFF the len + 1 wraps in 32-bit unsigned to 0 → malloc(0), after which up to len attacker-controlled bytes were read into that ~0-byte buffer.

Reachable via the file-comment string read in ctmLoadCustom (right after the header, for RAW/MG1/MG2), and again via UV/attribute-map name fields.

Fix

_ctmStreamReadSTRING (lib/stream.c)

• Allocate (size_t)len + 1 so the + 1 cannot wrap.
• Require the read to return exactly len bytes; on a short read (truncated/crafted file) free the buffer, null it, and fail with CTM_BAD_FORMAT.
• Set CTM_OUT_OF_MEMORY on malloc failure instead of silently ignoring it.
• Reject len == 0xFFFFFFFF explicitly, so the + 1 cannot wrap on a 32-bit size_t either (wasm32).
• Return immediately if an earlier read already failed, so a paired mName/mFileName read does not proceed with a garbage length (_ctmStreamReadUINT ignores short reads and its buffer is uninitialized).

Callers (openctm.c, compressRAW.c, compressMG1.c, compressMG2.c)

• Check mError after every _ctmStreamReadSTRING and stop decoding on failure (MG2 frees its temporary intUVCoords/intAttribs first). Previously the callers ignored the error and kept parsing.
• ctmLoadCustom resets mError to CTM_NONE up front. This PR adds the library's first reads of mError, and only ctmGetError clears it, so without the reset a context reused after an un-acknowledged failure would abort the next, valid load.
• ctmLoadCustom clears the mesh before returning on a rejected file comment, so ctmGetInteger does not report file-supplied counts alongside NULL arrays.

Verification

• Before: ASan build via the public ctmLoad() on the reporter's 44-byte crash_min.ctm → heap-buffer-overflow WRITE, allocation at stream.c:138, overflow at stream.c:141, chain ctmLoad → ctmLoadCustom (openctm.c:1236) → _ctmStreamReadSTRING.
• After: the same file is rejected cleanly with no ASan report.
• ASan harness against the final branch: crafted len = 0xFFFFFFFF and 0xFFFFFFFE, and a truncated comment, all return CTM_BAD_FORMAT with zero vertex/triangle counts and NULL arrays; a context reused after such a failure without calling ctmGetError then loads a valid file normally.
• Regression: a valid mesh (vertices, triangles, and a file comment) still round-trips through ctmSave/ctmLoad.

Follow-up (not in this PR)

Secondary, lower-severity items the reporter flagged: file-controlled vertex/triangle/UV/attrib counts drive malloc directly (openctm.c:~1239/1245/1254), enabling large-allocation OOM, plus an error-path leak. To be addressed separately.