Development is complicated. Not only because of the technologies and patterns that are required knowledge, but also because of the myriad of tasks ...
For further actions, you may consider blocking this person and/or reporting abuse
I am totally with you about all the problems you stated. Specially the thing about that damn DB script. that's always a big scary point in going into production: "we didn't miss any DB update right?". What we do regarding the different repos: frontend and API are different stories dependent on each other. Whenever possible we ensure that stories in the frontend who rely on a backend-story don't make it into the Sprint as long as the backend is not on production. Meaning we try to break down stories to the minimum deployable unit. So you focus on one thing during development and dependencies are sorted out by mid term planning.
sorry, got carried away by the repo-part. How I work thru a story? If it's not clearly defined, it doesn't make it thru estimating and planning. So I start defining which parts it touches (data layer, utils, buisness logic...) and then work my way up: write tests that define the behaviour, write code till tests are green, create pull request, next layer. If a pull request depends on one of a lower layer I mark it WIP with a reference to the version/pull request it's depending on.
How big is your team?
The whole team is roughly 8 devs. But on different technologies (web, iOS, Android, backend, 3D, core)
That sounds very similar to the process I follow where I work. We face a few unique challenges in our particular market but we're slowly working past them and changing attitudes along the way.
We're mostly a monolithic application transitioning over to small Java libraries. Because of that, we have a lot of dependencies (aka libraries) to manage. In order to address this, we pull our dependencies in via Gradle. This makes it easy to promote code in separate repositories without worrying too much about parts of a story getting ahead of the rest of the story, though that possibility is still there.
Another very nuanced and complicated issue for our particular situation is that we don't continuously deploy (currently... working towards it). We do continuously integrate, but deploying happens only after release which happens a few times a year. This is a pretty complicated issue given the customers we target, but I do feel it's the right choice (for now) given the constraints we have. As such, we don't have to worry about one part of a story going straight to prod since releasing and deploying is such a huge process at the moment.
Maybe to help understand this I should briefly describe our general process. It's pretty similar to yours:
After opening the PR on the core repo, the rest is automated. It'll eventually get into a "pre-release" type branch where it waits until the company is ready to release. Keep in mind that this is happening for 9 teams of 8-12 people each. Sometimes that causes issues but most of the time it runs smoothly. This process is also constantly improving. It's gotten significantly better since I started and we have goals to improve it even more.