I think this is not a bug.  Here is a simpler way to illustrate the 
issue:

def f(x): 
    for i in range(10): 
        if x: 
            pass 
        continue 
f(True)
f(False)

If you run the code above under trace, you get the following coverage:

    1: def f(x):
   22:     for i in range(10):
   20:         if x:
   10:             pass
   10:         continue       
    1: f(True)
    1: f(False)

Note that the 'continue' line is executed 10 instead of expected 20 
times.   This happens exactly as Amaury explained. If you disassemble f, 
you'll see

  2           0 SETUP_LOOP              34 (to 37)
              3 LOAD_GLOBAL              0 (range)
              6 LOAD_CONST               1 (10)
              9 CALL_FUNCTION            1
             12 GET_ITER            
        >>   13 FOR_ITER                20 (to 36)
             16 STORE_FAST               1 (i)

  3          19 LOAD_FAST                0 (x)
             22 JUMP_IF_FALSE            4 (to 29)
             25 POP_TOP             

  4          26 JUMP_ABSOLUTE           13
        >>   29 POP_TOP             

  5          30 JUMP_ABSOLUTE           13
             33 JUMP_ABSOLUTE           13
        >>   36 POP_BLOCK           
        >>   37 LOAD_CONST               0 (None)
             40 RETURN_VALUE        


Note how peephole optimizer replaced jump to the 'continue' line (5) 
from the 'pass' line (4) with a jump to the 'for' line by replacing

 4          26 JUMP_FORWARD             1 (to 30)

with

  4          26 JUMP_ABSOLUTE           13


I say this is not a bug because trace is correct in showing that the 
continue statement is never reached when executing f(True).