There is no standard method or pattern for synchronization of multiple (mutating) masters, when you cannot make any design changes to one of the masters (unless it already happens to have all the features you want).
You need to be able to detect changes since last time you checked. Bulk difference is out because you can only do that once per day, plus it probably would be unusable for real-time change detection anyway.
That means using some version numbering scheme, and that's a change to the master schema as well as to the approach to modifying data since the version number scheme requires maintenance during updates.
Ideally, you'd get push notification on changes to the master, but you are saying that is out of the question.
Still, you want real-time bidirectional synchronization. So, what you're looking for is known as magic, and does not exist.
Now if you also don't have control over the clients, then it's game over.
So, assuming you do have some control over the client, you will have to modify the problem statement & requirements to something manageable. With your system constraints, there is no way to keep everything in sync near real time.
However, a client might be able function by pulling a small amount of data from the server before making a change. So, the client isn't 100% in sync, but has enough to make some minor yet accurate changes.
Further, the client should consider these changes as tentative until they are replicated to and confirmed by the server.
This goes to a different client user experience than having a single centralized master store (which is what you're trying to emulate by having real-time synchronization with multiple masters).
There's no way to hide that the changes are tentative until confirmed, and that some changes having conflicts will have to be backed out and/or redone later. So, the user experience has no choice but to address that.
