Limits of renderer.info.memory when distinguishing leaked from cached Three.js resources

Three.js requires explicit dispose() calls on geometries, materials, and textures to release GPU memory, yet renderer.info.memory reports only aggregate geometry and texture counts. When meshes share geometries or textures, the library offers no ownership or reference-counting mechanism, so a rising count may reflect either a leak or an intentional cache. After dispose(), the JavaScript object remains syntactically valid and can be re-added to a scene, but the underlying WebGL buffer is deleted, producing undefined rendering behavior that is difficult to diagnose.

Texture.dispose() releases GPU memory but does not free the underlying HTMLImageElement or canvas, leaving CPU-side data intact until JavaScript garbage collection occurs. This gap between GPU and CPU accounting is not exposed by renderer.info.memory.

What is the documented boundary for safely disposing shared Three.js resources? Does renderer.info.memory provide any reliable signal for distinguishing leaked resources from intentionally cached ones? How can developers confirm that a disposed geometry or texture is no longer referenced by an active mesh before relying on the object again?