fix: cancel the pending speech-end timer when a call is torn down

[RaphaelFakhri]

Summary

stop() and the internal cleanup() set speakingTimeout to null without calling clearTimeout. The timer that emits speech-end stays scheduled, so it still fires after the call is torn down.

Problem

When the assistant is speaking, handleRemoteParticipantsAudioLevel schedules a speech-end timer 1 second out. If the call ends inside that window:

• speech-end is emitted after call-end, up to 1 second late.
• If a new call starts on the same Vapi instance, the stale timer fires during the new call. It emits a speech-end that does not match a speech-start, and it clears the reference to any timer that the new call has created since.

Solution

Add endSpeaking(). It clears the pending timer and, if the assistant was speaking, emits speech-end immediately so speech-start and speech-end stay paired. stop() and cleanup() call it in place of this.speakingTimeout = null.

Testing

Adds __tests__/speaking-timeout.test.ts (fake timers, no browser):

• The stale timer from a stopped call does not emit speech-end in the next call.
• speech-end is emitted once, synchronously, when the call is torn down while the assistant speaks.
• The normal speech-start then speech-end sequence is unchanged.

Run with npx jest __tests__/speaking-timeout.test.ts. Without the change to vapi.ts, 2 of 3 tests fail. With it, 3 pass. The full suite passes and tsc --noEmit is clean.

[RaphaelFakhri]

Closing to keep the number of open PRs here manageable. Happy to reopen if it is still useful.