Usually when you change your database structure, you would change the object that this is mapped into. If you were to change one without the other, that would be a monumental developer oversight. Adding a field without using it in many frameworks wouldn’t necessarily break it, so it wouldn’t be a bad change per se.
Any change you make to persistence should reflect as a bare minimum, the object data gets mapped into. This would likely be part of the same branch, and you probably shouldn’t merge it until it’s complete.
You’re looking for tooling to protect you from human errors, and nothing is going to do that. It’s like asking, how can I stop myself from choking when eating. You just know to chew. If this isn’t obvious, it’s a good lesson in development. Make one change at a time and make it right. Don’t rush off to presentation changes or logic changes until your persistence changes are complete. When you get into habits like this, it becomes steady, methodical and structured. Rushing is the best way to make mistakes and spend more time fixing them. Less haste, more speed.
For example, if I add a new field. I’d write the SQL, run it, populate a value, get that value and test it. Then I’d move on to the object mapping. I’d load it into the code, and get a bare minimum debug out to see it was loaded out, etc. etc… Small tweak, test and confirm, small change, test and confirm. Every step is validated so when it doesn’t work, you know why, you don’t guess.
Do you really need to make a case? Does your company not trust devs? Is there people leading that have no idea about technology? SVN is dead. Many devs won’t touch it. It’s best way to say to new candidates your company is backwards. Many would refuse to work in a company that uses a version control system that has been dead 7 years.