Expose mjtSize array fields as Int32Array in the WASM bindings

[VihaanAgarwal]

MjModel.tex_adr is mjtSize* (int64_t), and the generated binding exposes it through typed_memory_view, which surfaces it in JS as a BigInt64Array. Any arithmetic on its elements then throws: Cannot mix BigInt and other types in Chrome, can't convert BigInt to number in Firefox. That is the error behind #3496: the reporter's texture stage reads tex_adr, throws, and their material setup aborts, so the geom renders with the wrong color.

Scalar mjtSize fields already avoid this by casting to int in the generator, with a comment explaining that bigint does not fit the JS number model. This extends the same policy to pointer fields: the generator now emits an accessor that returns an Int32Array copy instead of a 64-bit view. The wasm heap is 32-bit addressed, so the values always fit. tex_adr is currently the only mjtSize* field in the public headers, so the regenerated bindings.h changes just that one accessor.

Before, against a two-texture model:

model.tex_adr          // BigInt64Array [ 0n, 786432n ]
model.tex_adr[1] * 3   // throws

After:

model.tex_adr          // Int32Array [ 0, 786432 ]
model.tex_adr[1] * 3   // 2359296

Added an assertion to the existing texture test that fails on main and passes with this change. Full wasm suite: 175 specs, 0 failures.

Fixes #3496