`shapes.js` mesh loading: `.obj`/`.gltf`/`.glb`/`.ply` skip the local-file proxy `.dae`/`.stl` use

[petercorke]

Found 2026-07-31, as a byproduct of checking whether sg.Mesh() can load
from a URL (it can't, reliably). loadMesh() (public/js/shapes.js:72)
handles mesh filenames two different ways depending on extension:

• .dae/.stl: rewritten to /retrieve<path> -- swift's own backend
  HTTP route that reads an absolute local filesystem path off disk and
  serves the bytes back. There's a comment confirming this is the
  intended design: "Mesh filenames arrive as absolute filesystem paths
  ... not URLs".
• .obj/.gltf/.glb/.ply: not rewritten -- part.filename is
  passed straight to the three.js loader's .load(), which fetches it
  via the browser's own fetch().

Since fetch() can't read an arbitrary local filesystem path, this looks
like .obj/.gltf/.glb/.ply meshes referenced by absolute local path
(the normal case -- e.g. URDF-referenced meshes from an installed
package) are currently broken for rendering, unless something not yet
traced compensates. Conversely, a real https://... URL would actually
work for those four formats specifically (accidental side effect of the
missing rewrite), but not for .dae/.stl (would get mangled by the
/retrieve prefix) and not for collision loading either -- spatialgeometry's
Mesh._init_coal() calls trimesh.load(self.filename, force="mesh")
without allow_remote=True, so trimesh refuses remote URLs there.

Not fixed, not fully verified either way -- found while answering a
question, not by reproducing the OBJ/GLTF rendering failure directly.
Worth an actual repro (add an OBJ-mesh example, confirm it fails to
render) before fixing, in case something elsewhere already compensates.