fix(inspector): release animation and texture state on teardown

[chiefcll]

Two retention paths in Inspector.ts, both only reachable with the inspector enabled.

Originally found while reviewing lightning-js/renderer#846. Of the four issues in that review, this repo has already fixed two — destroyNode(node) uses the mirror div stored on the node instead of a document-global getElementById, and the parent branch of updateNodeProperty already falls back with parentNode.div ?? this.root. The two below are still present.

1. activeAnimations never releases animations killed by destroy

Inspector.activeAnimations is a static Map holding the IAnimationController. Entries are only removed by trackAnimationEnd, which runs on stop / restore / waitUntilStopped or the controller's stopped event. A node destroyed mid-animation fires none of those, so the entry and the controller it holds are retained by a static root for the lifetime of the page.

Destroy now ends those animations as cancelled rather than deleting them outright, so getAnimationStats() and animationHistory stay consistent — restore() already records cancelled for the same situation.

2. textureMetrics pinned every texture ever used

It was a strong Map<Texture, TextureMetrics> on an object that lives as long as the renderer. setupTextureListeners detaches the old texture's listeners on every swap but never dropped its metrics entry, and destroy only cleaned the texture a node happened to hold at that moment. Every texture ever swapped off a node stayed reachable, bitmap included.

Now a WeakMap. Nothing iterates it — only has / get / set / delete — so the API is unchanged.

Testing

pnpm test green (360 tests, 42 files), tsc --noEmit clean, prettier clean, no new eslint warnings (the two reported on Inspector.ts are on main too).

No regression test here: this repo has no DOM test environment, and the inspector needs one to instantiate. The equivalent test — asserting getActiveAnimations() no longer lists a destroyed node — is in lightning-js/renderer#847, where happy-dom is already a devDependency. Happy to add happy-dom here and port it over if that's wanted.

🤖 Generated with Claude Code