Fix stale delayTimeout execution after Stop

[Ady0333]

Summary

This PR fixes an issue where pending block execution timers created during Run Slowly mode were not cancelled when Stop was pressed. These stale delayTimeout timers could fire after stopping the program and execute blocks from the previous run into the next run’s execution lifecycle.

---

What changed

Added cleanup in doStopTurtles() to:

• Cancel any pending turtle.delayTimeout timers using clearTimeout()
• Reset _alreadyRunning to false before the next run begins

---

Why this change was needed

runFromBlock() schedules execution using setTimeout and stores the handle in turtle.delayTimeout. When Stop was pressed, doStopTurtles() set stopTurtle = true but never cleared these timers. As a result, delayed callbacks from the previous run could still fire after Stop and execute runFromBlockNow() without any stop guard.

This caused _alreadyRunning to be set during the next run, which made runLogoCommands() treat the run as a premature restart. The natural-end path then suppressed onStopTurtle(), leaving the Stop button stuck in the active state and Save/Record controls disabled even after execution finished.

---

Scope

Affects only run/stop lifecycle cleanup in doStopTurtles().
No changes to block execution logic or scheduling behavior.

---

Verification

Enabled Run Slowly mode and ran a multi-block program.
Pressed Stop mid-execution and immediately pressed Play again.
Verified that execution completes normally and the Stop button resets.
Confirmed Save and Record buttons re-enable after run completion.

---

Impact

Prevents stale execution from leaking into the next run.
Ensures correct lifecycle termination after Stop → Play.
Restores proper UI state (Stop button, Save/Record) after execution.
No breaking changes.

[Ady0333]

@walterbender and @vanshika2720

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[vanshika2720]

LGTM @walterbender please review