Evaluate usage of tracker clock to ensure it's logically correct

To recap, the tracker uses an implementation of an Interval Tree Clock for resolving the causal history of replicated events. My understanding of ITC is that a scenario plays out like so:

- Node A is created as a seed clock
- Node B is created by forking A's clock
- Event X occurs on A, incrementing it's event clock
- When A syncs with B or vice versa, we can compare the clocks, and see that B's clock is strictly in the past of A's clock, so we can update B's state no problem
- If events occur on both A and B, their clocks will conflict, which requires us to resolve the conflicting state in some way, and then make sure the clocks are synchronized before proceeding

In the case of Swarm, we can deterministically resolve conflicts because at any given point in time, we know which node in the cluster "owns" a given process/registration, with the exception of processes which are registered but not managed by Swarm. We can ask the conflicted process to shut down, or kill it, and the registration will remain with the "correct" version. However, since the way synchronization works today is that the registry is sent to the remote node, I'm not sure a clock is strictly needed. If we assume that it does help us though, we should ensure that our logic for handling the clock forking/peeking/incrementing is correct.

No files, tests, or entry points are named. Start by tracing the tracker's Interval Tree Clock handling, especially clock forking, peeking, incrementing, and registry synchronization. Done means establishing whether the clock is needed and whether those operations correctly handle the described replicated-event scenarios.

Written by the indexing model from the issue text.