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).