Resolution:
There is no way to know that all servers in a cloud know about a subscription at any given time.  What does matters is that the server that the publisher is connected to knows that the subscriber is subscribed, which the call to TipcMonSubjectSubscribeSetWatch can accomplish. Before a client starts publishing messages on a given subject it is recommended that the client call:

TipcMonSubjectSubscribeSetWatch(“subject”,TRUE)

The returned message is a MON_SUBJECT_SUBSCRIBE_STATUS message which contains four fields:
a STR field containing the name of the subject
a STR_ARRAY field containing the names of the current RTclients that are subscribing to the subject
a STR field containing the name of the RTclient that just started subscribing to the subject (or "" if not applicable)
a STR field containing the name of the RTclient that just stopped subscribing to the subject (or "" if not applicable)
The watch is preferred to the poll call TipcMonSubjectSubscribePoll because the watch, which resides in the server that the publishing client is connected to,  gets triggered whenever the subscription table changes in the server. The ripple affect of a subscription moving through a server cloud should happen fairly quickly, especially in a hub and spoke architecture.