fix: guard Transport scheduling against stopped clock and stale time

[ssz2605]

PR Category

• Bug fix

What does this PR do?

This PR fixes three edge cases found after the Tone.Transport scheduling changes introduced in #7703.

Fixes

• Guard against stopped Tone.Transport

  • Some widget code paths stop Tone.Transport, causing scheduled callbacks to never execute.
  • This PR checks that the transport is running before using Tone.Transport.schedule(). If not, it falls back to the existing setTimeout scheduling path.

• Guard against suspended AudioContext

  • Tone.Transport.state returns "started" even when the AudioContext is suspended (the frozen context time still shows "started").
  • This PR adds an isClockRunning getter that checks Tone.context.state === "running" to distinguish a truly running Transport from a stuck one.

• Prevent scheduling in the past

  • In some cases, the computed transport timestamp could be slightly behind the current transport time.
  • This PR clamps the scheduled time to the current transport position before scheduling.

These are follow-up fixes to #7703 that improve robustness without changing the scheduling improvements introduced there.