Okay, so after seeing the .blend, I was wrong in my comment. (Because there have apparently been some changes made to how Blender handles IK.) However, these changes made to Blender aren't really great changes, and I'm still going to recommend doing it the old fashioned way.
So, first, let's explain what's going on. You are moving the chain via IK. The IK algorithm doesn't know about the limit rotation constraints that you've set for the IK bones, so while you're moving it, it's not using any these constraints. However, at the point that you confirm, it's then evaluating those constraints and so changing the bones' transforms.
Limiting the angles of IK with limit rotation constraints is, well, kinda hacky. Hopefully obviously here. (Limit rotation is a deceptively hard constraint to use well anyways, for reasons that are spectacularly math-y, particularly in world space like you're doing here.) It looks like Blender devs have tried to make it work, but it doesn't work well.
A much better way to get the IK you want is to delete these constraints and use IK angle limits and locks. You can see these by selecting a bone in pose mode and then looking at properties/bone/inverse kinematics. In this particular case, we want to lock Y and Z axes for all of the bones:

Note that these are no longer world-space limits on your rotation, like you had with your constraints, but I'd bet a lot of money that you didn't want them world-space anyways.
With this setup, it works fine for me-- but I'm still wary of the unusual structure. It's typical with an IK setup to designate a target for the IK constraint, but if this works for you, that's fine. The more typical way to do this would be to put the IK constraint on Mid, give it a chain length of 2, duplicate and unparent Upper and designate this duplicate as the target of the IK constraint, and finally give Upper a copy rotation constraint targeting the duplicate. (Which could be followed by a limit rotation if you wanted.)