fix(wasm): only rebase timeline when pace-drops drain the ring

The previous fix (552c823) rebased wallStart/rtpStart on every
pace-drop.  When decode throughput is slightly below source rate
(e.g. 25 fps vs 30 fps), the per-drop rebase creates a visible
sawtooth: smooth → drop → timeline jump → smooth → repeat.

Replace with a lighter touch: rebase only when the ring empties
completely from drops (the catastrophic stall that triggered the
original bug).  Individual drops are absorbed naturally by the
existing timeline — surviving frames stay on-schedule and the
gradual drift recovers without visible glitches.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: osamu620

web/rtp_demo.html

@@ -1547,16 +1547,14 @@ <h1>HTJ2K RTP Replay — Browser WASM Demo</h1>
       const target = wallStart + totalPausedMs + dtMs;
       const period = entry.framePeriodMs || (1000 / 60);
 
-      // Pace-drop: too far behind?  Discard and rebase the timeline
-      // anchor so the next surviving frame is scheduled relative to
-      // "now" — without this, every subsequent frame stays behind the
-      // stale anchor and gets pace-dropped too, stalling playback.
-      // Mirrors the "runaway rebase" in the native RTP receiver.
+      // Pace-drop: too far behind?  Discard and re-check next entry.
+      // If the ring drains completely, reset the anchor so the next
+      // decoded frame starts a fresh timeline instead of cascading
+      // into further drops that stall playback.
       if (paceDropEnabled() && rafTimestamp - target > PACE_DROP_PERIODS * period) {
         ringPop();
         droppedByPace++;
-        wallStart = rafTimestamp;
-        rtpStart  = (_ringCount > 0) ? ringPeek().rtpTimestamp : rtpStart;
+        if (_ringCount === 0) { wallStart = 0; totalPausedMs = 0; }
         continue;
       }