Fix VFS use-after-move crash by using stable handles for mjVFS

[NandiniDhanrale]

Summary

Fixes #3098.

mjResource::vfs and default mounts could hold pointers tied to the public mjVFS address. If wrappers moved mjVFS after mj_defaultVFS, close/read paths could hit stale pointers and crash.

This change stores a stable internal mjVFS handle inside mujoco::user::VFS, points resources/default mount to that stable handle, and tracks the current public owner pointer. Upcast now rebinds the owner pointer so lifecycle operations target the current mjVFS address after moves.

Code changes

• src/user/user_vfs.h
  • Add stable_vfs_, owner_, and Bind(mjVFS*).
• src/user/user_vfs.cc
  • Initialize stable handle (stable_vfs_.impl_ = this).
  • Use stable handle for default_mount_.vfs and
    es->vfs in CreateResource.
  • Use owner_ in self-destruct path.
  • Rebind owner in Upcast.
• est/user/user_vfs_test.cc
• Add UserVfsTest.MoveVfsAfterOpenResource regression test.

Validation

• Built user_vfs_test on Windows (VS 2022 toolchain).
• Ran new regression test: UserVfsTest.MoveVfsAfterOpenResource (PASS).
• Ran full user_vfs_test suite excluding AddFile fixture-path artifact (14/14 PASS).
• Ran issue reproducer (WrapperVfs C sample from VFS relies on mjVFS not being moved, resulting in segmentation faults #3098) against patched mujoco.dll (prints Exiting ok, no segfault).

[haroonq]

Please add a comment about what makes this "stable".

[haroonq]

Let's remove the owner_ member and the Bind functionality entirely.

We only need this pointer in order to perform the self-destruction. However, we only call SetToSelfDestruct from one place in the code. We can change that call site to capture the mjVFS it should destroy rather than having to keep the owner_ up-to-date on each bind.

[haroonq]

Thanks for this fix! I just have a couple small suggestions, but otherwise it looks good to me.