Ok, we have here now already a lot of answers giving advice concerning your question from the professional engineering and workplace aspects. I can more or less agree with all of them so I will keep in that regards my 2 cents for me and try to just give this answer considering the interpersonal point of view for your situation.
Disclaimer: Being on the autism-spectrum I might go into details that most won't even see as a problem. But since they were/are problematic for me, its the backup for my way of handling it.
So, the first contrast I am seeing here from most of the answers contrary your situation is, most people answering are professionals with prior experiences in QA.
As long not most of the employees in your company are senior developers, you can assume THEY don't have such prior experiences.
In my previous jobs I had always been "that nitpicky annoying coworker", but that was primary cause QA wasn't my job. The interesting thing I can tell you from back then is: People usually didn't disagree with me. They were just in a working culture not caring of quality and hence found someone caring for quality a restraining noise.
So keep in mind this might be the case at your work, too (Even if apparently it is supposed to be changed).
Let me tell you a little about my current job position. I know this is something that neither you can't implement alone nor is it a cultural change that can be implemented on short terms. But it might give you an idea of how to not be the nitpicky annoyance, if company's upper level is on your side1.
So contrary to my previous jobs I am now working for a very large company, spending a huge amount of resources for quality. I am not directly working in QA but as license compliance analyst, so in a break down it is still my job to validate other peoples code. Here actually any product has to pass our checks before it is allowed to be released. There are documented requirements a product has to meet, to be able to be checked by my team and all we need to do is checking it and giving approval or rejecting it. So it is not us deciding what hast to be checked. This has the result, that project teams aren't seeing us as the guys disturbing their deadlines, but rather ask us for help if their project isn't passing our analyses and they can't figure how to fix it2.
So taking this well working procedure into account, I would advice you the following:
First, and especially most important for me due to being an autist3, make sure to be certain about what is expected from your role. Despite nitpickyness is a good trait for an QA engineer, your company might have a wrong idea of what the responsibility of an QA engineer should be.
So make an appointment with your superior, and ask them to give you a clear definition of your responsibility in your role. Try avoid telling what you think your responsibility is about and asking for confirmation and rather let them explain their idea. Try to see their explanation fully separated from your own idea of what your responsibility should be, if you find it incomplete ask for clarification, but don't argue.
After that, write a proposal of your responsibility. Again just how you understood them, not what you think it should be. And then add a section to that proposal stating what is NOT your responsibility. Here you can add all the parts you think that should be part of your role, but have not been mentioned. The more you feel uncomfortable with something not being part of your role, the more dramatic my wording would be4.
Give that proposal to your superior and ask them to approve it.
Eventually adapt that proposal till its getting approved and voilà, you have a definite classification of your responsibility.
This gives you certainty in 3 ways:
You know what aspects of quality are important for the company and hence what you have to care for.
You don't need to worry about what you find important regarding software quality, as you have explicit written advice not to consider these aspects. This is also useful, to avoid being blamed in the future for not having taken care of these measures, as you have written advice to not to.
Most important regarding OP. It is not your personal opinion of quality anymore but a written treaty of what is the company's opinion of what should be assured. So you can't reasonably be blamed for it anymore. Or if it is part of the "not to"'s, neither you nor the developers have to bother, as the company clearly expresses not wanting that part to be covered.
1 What I hope they are, as otherwise your employment would be a farce.
2 Well, I am quite sure within their teams they still see us that way. But the point is, we don't have to tell them how to fix their code, rather they have to ask us what to do if there are problems with the code making it not pass our explicit defined and documented checks.
3 I just realized how much here can go wrong, when I came into a working environment where fortunately everything in every aspect is documented, and I noticed how much room for misunderstanding there had been in my previous jobs by the lack of such policy.
4I don't know if this is a good or bad advice, its just what I would do.