[dvd233]

When stop() and start() run before a pending animation-frame callback, that old callback sees _running become true again and starts a second persistent update chain.

Give each started loop its own ID so callbacks from earlier loops retire without scheduling or updating. Keep the deferred first update, scheduling-before-update order, pause/resume timing, frame-before-stage order, and manual update(true) behavior unchanged.

Validation on Node 18.20.8:

• 78 unit tests across 13 suites passed, including 10 loop regression/compatibility cases. The first new test reproduced two frame callbacks instead of one before the fix and passes after it.
• npm run lint passed.
• The real Animation class in Chromium, using native requestAnimationFrame and public APIs, produces one frame event per browser frame after repeated restarts and restarts inside stage.update(). Before the fix, one and three immediate restarts produced two and four events per frame. This is component-level scheduling validation, not full ECharts/GSAP/repaint or camera-speed coverage.
• npm run release remains blocked by the pre-existing TS2683 at src/canvas/Painter.ts:1254 (this.dpr inside a callback). Painter, the TypeScript configuration and dependencies are unchanged; the same error was present in the baseline installation's prepare step. No build diagnostics were disabled.

On Windows the Jest command supplies the existing test glob with forward slashes to avoid the Jest 27 path-normalization issue with the .agent-storage parent; the test scope and TypeScript diagnostics are unchanged.

Fixes #1170.