When the type reaches the upper limit of what numbers it can represent, the for-next loop adds 1 to it for the next iteration before testing to see whether to do another iteration, and since adding 1 to the upper limit makes 0, it is fooled to thinking there is more to do so it keeps going. It's not so much a bug it's just they haven't deliberately placed a protective mechanism in there to detect when this is happening.
I said exactly that just above.
You can change your loop type to something else, like a while-wend or repeat-until loop, and manage the counter yourself using bytes or whatever you want - you can then error-check for the upper limit being reached.
I hardly need help working around it. The point is, you can only work around if you know there's a problem, and how likely are you to think that Blitz messes this up when other languages don't?
We can argue semantics over the difference between a bug and "the lack of a deliberately placed protective mechanism" till the cows come home, but there's no good reason for it to behave as it does, and it's going to continue causing problems if it's not taken care of.