I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:
this is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well
patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.
communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.
Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?