Gunner, I don't know whether you may have solved this problem or not by now, but I'll toss in a couple suggestions and questions anyway. Since your original post stated you had a lead error PER THREAD, I'm assuming you mean the lead is either increasing or decreasing along the thread.
You mentioned using g71 with F and J values and then going to G33 where you could tweak the lead. Unless its a multiple start thread you can leave off the J word, as it will default to 1. F word is identical in g71 and g33, so the auto-threading cycle lead can be tweaked in g71 the same as in g33. Since the B value is controlling the approach angle, have you made sure its set to the nose angle of the insert or some lesser value? If it was set at a value greater than the insert angle, it wouldn't cause a variable lead, but it would sorta "stretch" the thread, as the point of the insert would be ahead of where it should be when you reach the final depth. Of course in this scenario the back side of the thread should look like hell too.
Since the A and B turrets both give identical results, that would seem to rule out Z axis encoders or screws. It's hard for me to imagine the spindle pulse generator could produce such a consistent error. I'm an admitted electronic idiot, but the spg is driven by a timing belt, so in order to produce consistent error it would have to be shifting somehow inside itself or generating some erroneous signal, but either would have to be at a very consistent rate. Possible, but doesn't seem likely.
Have you brought up the page which shows all active control data and checked to see that the executive code isn't somehow setting an E value other than zero? I'm assuming there's not some E value in your programmed code.
Do you get the same lead error regardless of the thread lead? In other words, have you run, for example, an 8tpi thread, and then a 16tpi thread and checked to see if the lead error per thread is the same on both or if it's half as much on the 16 as the 8? If the error is the same on both, that would again point to the program somehow picking up an E value from somewhere. If you add E0 to your g71 word, it would override any erroneous value of E residing in the executive memory.
Finally, if the lead error is the same regardless of the thread pitch, and you've verified the E value is indeed set to zero, remember you can use E values to correct the variable lead you have now, in either direction you like, back to a constant lead. It doesn't fix the problem, but with the E designation it would be easy to sell it to the brass as a long forgotten Error compensation value
Oh...almost forgot.....there are some variables which can be set in user task. Some of them relate to specifying lead and lead error comp. I've never fooled with them, as I've had no occasion to, but I know they're there and might be something else to look at.
If you have found the problem in the interim, I'd like to know what it was in case I run into the same thing on one of mine.