You're probably not going to like this answer.
Here's how this is likely to be perceived by anyone you escalate this to who isn't a designer:
Your design team is led (you haven't said whether that designer is the head of the team on the org chart, but it doesn't matter, it's the de facto state of affairs) by a highly experienced, educated, and knowledgable designer. The extensive reviews of your work is mentoring, rather than micromanaging, the rest of the team. The work is getting done, presumably to a satisfactory quality level; it's getting done quickly, and literally nobody cares who gets the "credit" for it. Design thinking, use cases, and user testing are time consuming and unnecessary, because this designer has been doing this for 25 years, they've got a doctorate, they knows what they're doing.
That's what you're up against. I'm not saying that's it's correct, or a good way to run a design team -- it isn't -- I'm saying it's how it is likely to be perceived by management.
Now, it's possible that they really are that good: experienced, talented designers genuinely can get away with skipping over a lot of the usual design process for relatively routine tasks -- which, honestly, many design tasks are -- because they've done it a bunch of times already and seen the results.
It's also possible that they're one of those people who's just really good at office politics, surrounds themselves with juniors who aren't experienced enough to challenge them, has the same bag of design tricks they reach into every time, and is just coasting until retirement.
You're in a better position to judge which of those is the case for this particular person than we are. But either way, my advice is more or less the same:
Don't go up against them. Learn from them.
Use your time in this (probably dysfunctional) team to position yourself for a better situation in your next job.
If they're a good designer, those extensive micromanaging design reviews are a real learning opportunity. When they asks for changes, try to find out the intent of those changes -- not necessarily pushing back against their decisions, but truly to understand why they're recommending them. (You may find that asking these type of questions will improve your position in the team.) If they're a bad designer, same deal, except that you use that bad advice to hone your own understanding of why it's bad advice, and of how if left to your own devices you might be able to do it better.
"Credit" within this team is unimportant. The way designers earn credit is by building a portfolio, not by getting kudos from management. Keep clean copies of your own best work for later. Take advantage of the fact that the micromanaging is augmenting your portfolio; or keep a copy of your own work from before the designer made you ruin it. (Either way you can study and learn from the difference between the two versions.)
You may make some headway with the "shouldn't we be doing some user testing" and "shouldn't we be iterating on this design post-development" questions. In both cases do it through them, not by trying to escalate over their head; if they're not on board it's not going to happen anyway.
I know this is deeply unsatisfying, and less about UX than about office politics. But that's a big part of the job, unfortunately.