[Unity plugin] Surface a clear error when mesh asset is missing

[ingyukoh]

Related to #1354.

Summary

When an MJCF references a mesh whose asset failed to import — or whose name collides with another asset of a different type in a Resources folder — Resources.Load<Mesh>(assetName) in MjMeshShape.FromMjcf returns null, the Mesh field is left null, and downstream code (BuildMesh, DebugDraw) throws an opaque NullReferenceException far from the actual cause. This patch surfaces a descriptive exception at the load site so the user hits the importer abort path with a message that points at the real problem.

Context

The typed Resources.Load<Mesh>(assetName) fix BH proposed in #1354 is already in main. That fix resolves the case where both a Mesh and a non-Mesh asset of the same name exist (the type filter returns the Mesh). It does not, however, help the case where only the non-Mesh asset survives import — there the typed load returns null and the failure becomes silent.

This PR is intentionally scoped to the diagnostic gap, not the runtime resolution behaviour.

Diff

     if (!string.IsNullOrEmpty(assetName)) {
       Mesh = Resources.Load<Mesh>(assetName);
+      if (Mesh == null) {
+        throw new Exception(
+            $"Could not load mesh asset ''{assetName}''. The MJCF references a mesh "
+            + "that was not imported, or another asset of a different type (e.g. a "
+            + "material) shares the same name in a Resources folder.");
+      }
     }

MjImporterWithAssets.ImportString already catches Exception and deletes the partial asset directory, so throwing here cleanly aborts the import with the asset cleanup it already does today.

Test plan

• git diff --check
• Unity EditMode test suite (no changes to existing tests; new code path only triggers on a deliberately broken MJCF — adding a regression test would require setting up a temporary Resources folder with a .mat-but-no-.obj asset name collision, which I can add in a follow-up if you want it)

If you would prefer the diagnostic as a Debug.LogError rather than an exception, happy to swap.

[Balint-H]

A reasonable tweak to make errors with imports from broken MJCFs more instructive. Could also be useful for the future when there are new mesh formats in main MJ that haven't been implemented in Unity yet. Please adjust the wording of the error message based on the feedback!

[Balint-H]

I thought that non-mesh assets that share the name are no longer the issue. The failure is only when a mesh was not imported, or there was a failure in the import, no?

If that's the case, the second half of the error message sentence is unhelpful/redundant.

[ingyukoh]

Thanks — wording updated. Dropped the type-collision clause since #1354 already handles that case, and replaced it with the unsupported-mesh-format scenario you mentioned.

[Balint-H]

Thanks for the rephrase. LGTM. Could I get your help with approval @erez-tom?