I had a similar problem with an architect on my team. I realized that the architect was spread too thin, so by the time they came back to discuss or look at something again, they would not have time to remember what they had recommended previously. I went through a few cycles where I would implement a change they asked for, and then they would ask me to change it again in a slightly different way, because they forgot what they recommended previously. 

While this code is the most important thing happening for you, it is only one of a thousand tasks that are competing for space in the tech lead's brain. I would recommend a 1-on-1 and fill it with questions, not statements. That's what I did when I encountered something similar, and it was incredibly helpful. I was able to get a grasp on the larger goals the person was targeting for the code, so I could write code in line with their larger goals. 

You can also walk through the code during the 1-on-1, so you can get more details on why they are asking for what they're asking. The fastest way to remove the review comment back and forth is to have the conversation over a call or in person. 

Tech Lead @ Centene

Spencer Romberg

I've made similar pivots in my career as a full-stack dev. I went from a mostly web-based FSE to a fully mobile FSE. I talked up my mobile experience in my resume and applied for roles that were mobile-heavy, but listed as full stack. 

In my opinion, full-stack hires are often "unicorn" hires, so it's easier to land a role without having deep experience in one area of their stack as long as you show competency and experience in other areas. If I were in your shoes, I would apply for backend-heavy full-stack roles for your next job, and then jump from that role to a pure backend role. 