PlaybackSpeed, Long-running processes, Weird non-blocking behaviour

**Describe the bug**

Like the title says, I'm seeing some weirdness with PlaybackSpeed, long-running processes, and non-blocking behaviour. Honestly not sure if this is a request for help, a bug report, or a feature request.

**Setup**

Ubuntu / bash / gnome-terminal, vhs version v0.7.2 (484e440)

**To Reproduce**

Sleep a long time to simulate a long-running command, and try to speed up the recap in the recorded gif.

**Source Code**

Here's an example test.tape:

```
Output img/test.gif
Set Shell "bash"
Set FontSize 22
Set Width 1200
Set Height 1000
Set TypingSpeed 100ms
Type "sleep 2; echo done sleeping 2s"
Enter
Sleep 3
Set PlaybackSpeed 100
Type "sleep 100; echo done sleeping 100s"
Enter
Sleep 3
Type "echo doing next thing"
Enter
Sleep 3
Type "finishing immediately"
Enter
```
**Expected behavior**

If I sleep 100s and have 100x playback, I'd expect the recording to show a pause of 1s and then show "done sleeping 100s".
I'd also expect that vhs takes at least 100s to record the video, because it has to record in real time even if the playback is sped up.

**Actual behaviour**

3s into the 100s sleep, "next thing" prints, as if vhs got bored waiting on the first longer sleep.


Based on the output from `vhs test.tape` during generation of the above, it looks like it indeed just skips to the next steps in the middle of the 100s sleep, but shouldn't these be blocking steps that run in series?

**Additional context**

My use case involves recording a terminal session where there are several commands, some returning in seconds and some taking several minutes. Fast things don't need to be faster, but the slow things do actually need a *large* speedup because most of the time is spent waiting and there's not screen changes (ie just polling a cluster until it's ready). I can't know in advance exactly how long it will take for the commands to run, so adjusting timing pauses and playback speed doesn't work very well.

Rather than adjusting playback speed based on multipliers like 1x or 100x a base speed, what might be much more natural is to allow the user to set a maximum playback length, then let the system determine the framerate/playback speed that works.

I'm probably doing this wrong. None of the examples in-repo seem to involve long-running commands, much less commands with kind of randomized run-times, but that seems like it would be a common use-case.

Reproduce the issue with the provided test.tape and `vhs test.tape`, using the long `sleep 100` command with `Set PlaybackSpeed 100`. Trace the PlaybackSpeed handling and command execution path to determine why later tape steps run before the command finishes. Done means long-running commands remain sequential while the resulting recording applies the requested playback behavior.

Written by the indexing model from the issue text.