I suspect that the scanner is just briefly mis-decoding the call's link control data and seeing a different talkgroup number. That would cause it to start scanning the 20 channels. If it was doing proper trunk tracking, it would return to the control channel and then quickly get redirected back to the voice channel.
If Whistler isn't going to decode the control channel, then they should at least implement more robust logic, i.e.don't leave a voice channel unless a couple of sequential link control messages indicate that a different talkgroup is using the channel.