Wow.
I’m hesitant to continue commenting, because you have clearly bought heavily in to the design pattern you’ve decided on.
If at some point, you decide you’re open to a (potentially massive) rearchitecting, I would suggest reading the property binding syntax section of the Angular template syntax overview first. Then, this post on an alternative paradigm to (ab)use of lifecycle events for propagating model changes across an app.
The fundamental problem I think you’re running into (and, believe me, I also bashed headfirst into this for literally months when I first started out with Angular) is an imperative mindset, whereas webapps are reactive in nature. You seem to be looking for ways for children to expose API endpoints for parents to call. Instead, the typical idiomatic approach in Angular would be to do this communication via @Input and @Output bindings declared by the children, so the parent pushes data instead of calling functions (on the child side, ngOnChanges can be used as a hook to know when these have changed) and reacts to events emitted from the children.
Again, as it seems you have a ton of inertia in this code base, it wouldn’t be particularly reasonable of me to expect you to drop everything you have so far, so I will leave things at this for now and see how you want to proceed.