Though if that were about to happen, I would presume miners and pools would use invalidateblock to blacklist the BIP 110 side (if total work on the BIP 110 side were to approach attaining greatest work), at least until Core did a release in response, with that protection hard-coded, or whatever other wipeout protection they'ld implement.
Why would BIP110 opponents wait that long? With the current hashrate distribution and RDTS having ≤ 1% of the hashrate, the Bitcoin chaintip will find scores of blocks before RDTS finds a single one. As you say, all the blocks mined on the Bitcoin chaintip would be at risk of being reorged if RDTS ever pulled ahead. It seems obvious that a reorg of 100 block depth would be unacceptable to the network. The reasonable thing would be to nip it in the bud immediately. So, people that don’t support BIP110 should run invalidateblock on the first RDTS block once the Bitcoin chaintip has progressed 100 blocks from the mandatory signaling height. Since RDTS will be way behind at that time, people can run it safely at different times and it would work fine regardless (although I expect it to be completely unnecessary in the first place).
Why would BIP110 opponents wait that long? With the current hashrate distribution and RDTS having ≤ 1% of the hashrate, the Bitcoin chaintip will find scores of blocks before RDTS finds a single one. As you say, all the blocks mined on the Bitcoin chaintip would be at risk of being reorged if RDTS ever pulled ahead. It seems obvious that a reorg of 100 block depth would be unacceptable to the network. The reasonable thing would be to nip it in the bud immediately. So, people that don’t support BIP110 should run
invalidateblockon the first RDTS block once the Bitcoin chaintip has progressed 100 blocks from the mandatory signaling height. Since RDTS will be way behind at that time, people can run it safely at different times and it would work fine regardless (although I expect it to be completely unnecessary in the first place).