refactor: use THREE.Timer instead of deprecated THREE.Clock

[onderilkesever]

Summary

THREE.Clock was deprecated in three.js r183 in favor of THREE.Timer. Consuming apps on three r183+ see a console deprecation warning the moment a SparkRenderer/OldSparkRenderer is constructed, since the constructor unconditionally does new THREE.Clock().

Both renderers only ever read elapsed time once per frame (clock.getElapsedTime()), and deltaTime is derived independently (time - previousTime), not from the clock. So the swap to Timer is a small, local change: call timer.update() once per frame, then read timer.getElapsed().

• cloneClock (in utils.ts) is removed. It doesn't have a Timer-compatible equivalent since Timer exposes no public fields to copy — sharing the passed-in Timer instance directly is the more idiomatic way to sync time across systems anyway.
• Updated both SparkRenderer and the legacy OldSparkRenderer (still exported from index.ts) for consistency.
• Rebuilt dist/ and updated the clock row in docs/docs/spark-renderer.md.

Breaking change — flagging for discussion

This renames the public option SparkRendererOptions.clock?: THREE.Clock (and OldSparkRendererOptions.clock) to timer?: THREE.Timer. Any caller passing a custom clock will need to switch to timer. Happy to add a deprecated clock alias for back-compat if preferred — wanted to surface the tradeoff rather than assume.

Test plan

• npm run lint / npm test (via pre-commit hooks) pass
• npm run build (dev + production) succeeds; verified no THREE.Clock references remain in dist/
• Manual smoke test in a browser against three r184 (no deprecation warning, splats render with no first-frame time jump) — please let me know if you'd like a recording/screenshot