@Svyatoslav Well, not really. As I mentioned in the post, putting the whole WP into one repo means I'm versioning code that's not mine and I don't want that. As to putting the versions in the theme or plugin files, while it's great to track compatibility requirements, it's not great for what I am trying to achieve.
You're saying "don't change anything on stage/prod manually (only thru pushes)", but that's exactly the issue. While that would be a normal and safe way of handling things with any other framework, I've come to find that Wordpress websites require updates so frequently that we do do them in production directly, there's even a way to enable auto-updates for plugins!
I agree with you that in a perfect world, each update should be done on a local environment first, tested, then pushed, tested in staging, and finally deployed to prod. But the reality of the field, in my experience, is that clients that have WP websites:
Don't mind the risks of updating directly in prod (downtimes would be less expensive than getting entirely hacked)
Do not have the budget to have a developer keeping an eye on the updates every single day to test and push them
Would rather pay to have their website fixed if an update breaks it in production rather than pay devs to test each update beforehand
It's also worth to note that in my experience, updates rarely break websites when it comes to Wordpress. Only times I've seen it happen were when I was updating from multiple major versions down. And even then it was usually mostly fine!