Fix/validate mesh face indices

[aWarmWalrus]

Validate mesh index arrays in mj_validateReferences

Problem

When loading a binary model (.mjb), mj_loadModelBuffer reads the whole
mjModel buffer verbatim from the file and validates it only through
mj_validateReferences. That function checks the *adr/*num arrays but not the
contents of the mesh index arrays mesh_face, mesh_polyvert and mesh_polymap.

At runtime these are used as unchecked offsets, e.g.
mesh_vert + 3*(mesh_face[...] + mesh_vertadr[meshid])
in engine_ray.c, render_context.c, engine_collision_sdf.c,
engine_support.c and engine_collision_convex.c.

The XML compiler already rejects out-of-range indices
(mjCMesh::CheckMesh, user_mesh.cc), but that path is bypassed for binary models.
As a result a crafted .mjb with an out-of-bounds vertex index loads successfully
and then causes an out-of-bounds read (crash, or silent adjacent-heap read for small
overruns) as soon as the mesh is ray-cast, rendered or collided.

Repro (before this change)

A .mjb identical to a valid model except mesh_face set to 100000000
(with nmeshvert == 4) loads via MjModel.from_binary_path with no error, and a
single mj_ray against the mesh segfaults.

Fix

Add content bounds-checks for mesh_face, mesh_polyvert and mesh_polymap to
mj_validateReferences, mirroring the compiler's checks. The *adr/*num arrays
iterated here are already validated by MJMODEL_REFERENCES earlier in the same
function, so the iteration is safe.

Follow-ups (not in this PR)

mesh_graph, bvh_child/bvh_nodeid, and the skin_*/flex_* index arrays share
the same root cause and warrant equivalent validation.

Testing

Adds ValidateReferencesTest.Mesh in test/engine/engine_io_test.cc, which corrupts
mesh_face to an out-of-range and to a negative index and expects
mj_validateReferences to report mesh_face (and to return null once restored),
following the existing GeomCondim/Texture cases.

src/engine/engine_io.c was syntax/type-checked locally with
gcc -fsyntax-only -Iinclude -Isrc (clean). The full test suite was not run in my
environment (no MSVC/Clang toolchain set up here); please rely on CI to execute the
added test.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[aWarmWalrus]

@google-cla check

CLA should work now.

[sylvesterkaczmarek]

This leaves the same MJB out-of-bounds-read class open through mesh_facenormal. Binary models load that array verbatim too, and both classic and Filament rendering use each entry as an unchecked local index into mesh_normal (for example mesh_normal + 3 * (mesh_facenormal[...] + normaladr)). A crafted MJB can therefore pass these new checks with a valid mesh_face but an oversized face-normal index and still read outside the normal buffer. Could mj_validateReferences also validate each mesh_facenormal entry against the owning mesh's mesh_normalnum, with a corruption regression alongside mesh_face? mesh_facetexcoord appears worth auditing for the same reason, accounting for its no-texcoord sentinel semantics.

[aWarmWalrus]

Ah yes good point, updated with mesh_facenormal checks and mesh_facetexcoord checks as well.

[sylvesterkaczmarek]

Re-reviewed current 2cf65cd. The added validation now covers mesh_facenormal and mesh_facetexcoord with the correct no-texcoord guard, and the regression exercises oversized and negative indices plus the mesh_texcoordadr == -1 case. My earlier blocker is resolved.