Chain replication is used to move into another environment without manual intervention. Since it is publish instance you might have configured after replication is complete from author to flush the dispatcher etc.... Out of the box stores the replication property only at jcr:content. In your case it is jcr:content/vrt/cq: lastReplicated instead of jcr:content/cq: lastReplicated which indicates some customization done in pre processor & you need to verify the custom code Or third party code used here. Again as you guessed jcr:content/vrt/cq: lastReplicated/cq:lastReplicated sounds to be custom code issue & practically you can;t have property within property.
P.S:- Generally the thread I pick up try to answer any follow up question, The new community feature of "listing based on creation user instead of last modified user" nor "the inbox feature" is not friendly for an followup. If missed any followup please create a new thread.
Conflict may not be with replication module. There might be other module like workflow updating the same asset. In short two thread worked on same asset & first one wins. Last one fails. Configure logger writer in trace level for class org.apache.jackrabbit.oak.jcr.operations.writes. and verify which are those two threads.
The last log line is a bit strange (cq:lastReplicated/cq:lastReplicated should probably just be cq:lastReplicated).
So it looks like the replication servlet is removing the property while some processor is setting this property. I have no idea what the thread "Adobe Granite ChainReplicationService Processor" is for.