I would _expect_ the globalCallID/callManagerID to remain the same for the call - I think the combined ID gets generated at the time its created and remains throughout its lifetime, regardless of which CUCM is actually performing call control ops on it.
In general, if a provider loses connection with a CUCM you will see all of your addresses/terminals go out-of-service, then the provider go out-of-service - when connection is restored (e.g. JTAPI fails over internally to a secondary CUCM) the opposite sequence will occur. For calls in progress on an address that goes OOS->IS, you would receive a set of 'snapshot' events to catch your implementation up with the current call state.
The idea is that if your code can gracefully handle these out-of-service/in-service events, then you don't need to write any _specific_ HA code, at least for HA on the CUCM side. Things will just go OOS/IS whether it is due to network connections, CUCM down, CTIM down, administrative changes (e.g. your JTAPI user CTI permission gets removed/restored.), etc.
Implementing HA for your side is different set of concepts. Generally, both your primary and secondary would open their providers with primary/secondary CTI managers specified. Assuming CUCM is stable and one of your app nodes fails, then you will need to figure that out somehow (some kind of inter-app heartbeat?), in which case you can start doing positive operations (answering/distributing calls, etc.) from your secondary.
