[ScottBurson]

There may be some truth in this, but I think it's overstated. The OP did speak up about major issues with the project, even suggesting moving people from the front end team to the back end team, which was done.

I don't think there's much one can do about an co-worker at one's own level, who is successfully blaming everyone else for the project's problems, accumulating influence, and driving away competent subordinates. You just have to get out. Eventually management may figure out the real problem, but if they don't get it yet, you can't wait around for them to get a clue.

[FennNaten]

From what I read, OP did speak up at the beginning to say that backend was late, but never directly put K's methods as the center issue, to avoid 'pointing fingers'.

Even when transferred team members complained, before leaving, OP didn't state in the text that anything was brought up to management.

There are orgs where managers 'above' the team lead level are completely clueless about the technical side, and OP's company seems to be of this type if K's getting away with her behavior, meaning that she can bullshit her way through this if nobody on the same level rises the issue.

Still, I'd agree with getting out of this type of org anyway, but upon reading I just feel like OP didn't 'fight' properly. There are several levels of action that one can take in this situation: trying to influence the coworker's behavior, face to face discussion, documented report of what's wrong to management, asking for an assessment of project state by another experimented tech lead... And these actions have to be taken early on, quitting being the last resort.

Note that I'm bringing this up because I haven't seen these mentioned explicitly in OP's writeup, so I assume that none of these strategies have been tried, but I may be wrong.