fix(ImageTrail): stop the render loop and drop listeners on unmount

[noron12234]

The bug

ImageTrail's effect constructs a variant class and returns nothing:

useEffect(() => {
  if (!containerRef.current) return;
  const Cls = variantMap[variant] || variantMap[1];
  new Cls(containerRef.current);       // no handle kept, no cleanup
}, [variant, items]);

Every one of the eight variants starts a self-scheduling loop:

render() {
  ...
  requestAnimationFrame(() => this.render());   // never cancelled
}

and every ImageItem registers a listener that is never removed:

window.addEventListener('resize', this.resize);

So unmounting the component leaves the rAF loop running forever, still
calling lerp, gsap.killTweensOf and gsap.timeline against detached
nodes, plus one leaked window listener per image and two leaked
container listeners per instance.

Why it compounds

The dependency list is [variant, items] and items is an array prop. A
parent rendering <ImageTrail items={[...]} /> inline hands over a fresh
reference on every render, so the effect re-runs and builds another
instance. The previous one is never released, so the leak accumulates
with parent renders rather than being a single stranded loop. React
StrictMode makes it visible immediately: two live loops after the first
mount.

The fix

• ImageItem gains destroy() to unregister its resize handler.
• Each variant keeps the pending frame id and the two container handlers
  so they can actually be released, and render() returns early once
  destroyed.
• Each variant gains destroy(): cancel the pending frame, remove the
  four container listeners, kill the GSAP tweens still targeting the
  images, dispose every ImageItem.
• The effect keeps the instance and returns a cleanup that calls it.

No behavioural change while mounted. Applied to all four variants of the
component (JS/TS x CSS/Tailwind).

Third commit: a fix that never shipped

Rebuilding the registry surfaced something separate. src/ carries the
StrictMode rAF fix for LineSidebar and OptionWheel (cleanup nulls
rafRef.current so the loop can restart), but public/r/*.json was
never regenerated after it landed, so it still holds the pre-fix shape:

if (rafRef.current != null) return;   // still in public/r/*.json today

with no rafRef.current = null in the cleanup. Since the registry is
what the jsrepo CLI writes into a user's project, that fix is currently
not reaching anyone installing through the CLI. Regenerated with
npm run registry:build; no source change in that commit.

Verification

• eslint clean on both JS variants (--max-warnings 0, exit 0).
• tsc --noEmit reports zero ImageTrail diagnostics.
• Registry regenerated with npm run registry:build; the only artifacts
  touched are the four ImageTrail files plus the eight stale
  LineSidebar/OptionWheel files described above.