It is very important you make code that satisfy what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting everytime your leaders.
If you think something is wrong and you are relatively expert in your field then chances are high your are right.
Here are some statements that could be usefull to you.
- I was requested to do X, code reviewer suggest also Y, should I do it or should I move to more important stuff
- You are suggesting me Y, then you can figure out at least 1 test case that would catch that behaviour so I can test it? I believe that code won't be called.
- Maybe shouldn't we develop a safe fall back for uncovered cases first? so we catch them early and fix on the go so we can focus on more important stuff.
- I Was requested X, I think I could do Y unless there are other priorities, why next time don't you file a feature request instead of putting it as review to my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than 1 person, usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)
Do you seriously think that the attitude of your reviewer is damagin the project or do you think he's right most times (except maybe sometimes he just make minor errors in evaluation and eggxagerate that)?
Too me sounds more like he's writing stuff that does not belong to a code-review, which is bad practie because makes harder to track stuff for everyone. However I don't know what other reviews he made, so I can't say anything on other cases.