OK, finally I had some time to take a deeper look into this. And yes, I can reproduce it! Whenever you scrub *backwards* using the scrubbing tool, Pro Tools calls prepareToPlay() a few times with different (smaller) buffer sizes. The subsequent calls to the audio callback will then also use that smaller buffer size. As soon as you stop scrubbing backwards, everything reverts back to the original buffer size.
I think there is nothing we here can do about it - if we are in the prepareToPlay() callback, there is no way to tell whether we are scrubbing or not, it seems to be a weird quirk of Pro Tools that we have to live with.
However please keep in mind that the buffer size passed into prepareToPlay() is only a hint anyway. It doesn't come with a promise that the next audio callback will actually use that buffer size. It might be called with a smaller buffer size even without a prepareToPlay() callback in between that announces that buffer size change -- hosts are allowed to do that.
So I think the best strategy would be to implement prepareToPlay() in such a way that you just ignore the call to it whenever it's safe to do so.
For example: the first time prepareToPlay() is called, it is passed a buffer size of 1024, so you do your initialisation and allocate your resources. Then, the user scrubs in ProTools, and prepareToPlay() is called again with other numbers like 256, 128, ... which are smaller than the original first call - so it's safe to just ignore it. You already allocated everything! An interesting detail is that ProTools never calls releaseResources() in between those spurious prepareToPlay() calls, so it's actually safe to ignore those additional calls.
I'll add a comment to prepareToPlay() saying that it might be called spuriously and that you should keep that in mind when implementing it.
Is that satisfactory?