fix out-of-bounds read when matching IFS header keywords

[aysha-afrah26]

The strings in an IFS header are length prefixed, and IFSReader::readHeader copies each one into a new char[] sized by that prefix before handing it to strcmp. The prefix comes straight from the file, so nothing guarantees it covers the terminating null character that IFSWriter appends, and on a header that leaves it out strcmp walks off the end of the allocation. I noticed the mismatch while reading the reader against the writer and confirmed it under ASan: a file storing its magic as length 3 followed by the bytes IFS gives a heap-buffer-overflow read on the magic comparison, and the VERTICES keyword in the header loop and the TRIANGLES keyword on the mesh path behave the same way. Routing the three comparisons through a small helper that compares only the characters it actually read keeps the parse inside the buffer, and since the helper consumes the field even when it does not match, the stream stays aligned for the next element. The cloud name was being copied into a file-sized allocation only to be thrown away, so it now skips the bytes instead. Keywords are still accepted with or without the trailing null so existing files keep loading, and the test covers both the cloud and the mesh entry point.

[larshg]

Suggested change

	const auto append_unterminated = [&data, &append_bytes, &append_uint32] (const std::string& str)
	const auto append_unterminated = [&append_bytes, &append_uint32] (const std::string& str)

&data was not used and thats why it failed on MacOS.

[aysha-afrah26]

Good catch, that's it. data only gets touched through append_bytes, so capturing it directly was dead weight and -Wunused-lambda-capture flagged it under -Werror on the clang macOS jobs (the Ubuntu ones don't set -Werror, which is why they stayed green).

Applied your suggestion in 644ca49. Reproduced it locally with Apple clang and the macOS CI flags first: test/io/test_io.cpp:1853: error: lambda capture 'data' is not used before, clean after, and the test still passes under ASan for both the cloud and the mesh path.

[mvieth]

Looks good to me, thanks