So, first, I think you have a management problem. It sounds to some degree like there's an "us against them" philosophy, where test is seen as an obstacle to release, not an integral part of the Development process. A good developer, in my experience, is fully aware that they're human, and will make mistakes. They understand that test is there to protect the end user, and both the developer and the tester are equally important to the overall effort. Things to look at include questions like is there a path for advancement for testers in your organization? Or is test seen as a way to get into development? If there isn't a path for testers to become senior testers, and have as much influence on the development process as a lead developer, that's probably a problem. If developers become defensive when you report defects, that's a problem. And it's not necessarily something you can solve without help from management. For example, if the developers are evaluated on how many defects are found in their code, then that's a recipe for a contentious relationship.
Second, since you're a black-box tester, you have an opportunity to understand the system as a whole better than any developer does. As a general statement, developers understand their area of expertise quite well, but they don't understand how their piece works with everything else, or with the surrounding infrastructure. This is often true of architects as well. You have an opportunity to become an expert in this, and a real advocate for the end user.
Third, just like developers aren't perfect, neither are testers. That's why you shouldn't be just testing code. Your job, along with everyone else's, should be improving the process to make defects less likely to end up in the code, and more likely to be found when they do. Sometimes, this means writing code so that it's easy to test. What process you're using, waterfall vs. agile, doesn't matter. What does matter is that you look for places the process can be improved, and defect discovery can be done as early as possible. To take your example of bug rediscovery, why didn't the developers have unit testcases that could detect the bug, after you'd reported it the first time? Or if you found a symptom of a bigger problem, why didn't they realize the problem was bigger than it was? You're not the only person responsible for software quality.
And, finally, it's far better to find and report a bug, even if it's late in the cycle, than to not find the bug. Would you/they prefer it be found in the field? Note that this doesn't mean that it isn't sometimes/often appropriate to defer fixing a bug to the next release, but that decision should only be made after the impact of the defect is understood, along with the likelihood of hitting it. If it is a serious bug, then you should figure out why it wasn't found earlier. Was it because there were bunches of other bugs that were blocking finding this one? Was the bug introduced as a fix for another problem? Maybe having more people testing would surface bugs earlier.