This seems like an API gap. I understand you need a common type to be able to inspect the move without code duplication.
The first suggestion would be to use their common ancestor, the AbstractMove, as the filter type argument. But if you need to look at the subchain, then AbstractMove won't help. In that case you need to use instanceof check to see if it's SubChainReversingChangeMove or SubChainChangeMove and then in two if-branches downcast the move, extract the information and make the decision.
To make that more convenient we should introduce a common interface for both move types. That should be fairly easy. But notice that although move filtering is documented, the Move API (including all specific moves) is in the impl package, so it's not the public, stable API. It's internal and its backward compatibility is not guaranteed. On the one hand, that allows us to still evolve the API and fill in the gaps like this one, but on the other hand, such changes might break users' code and we should be careful about that although the backward compatibility is not guaranteed.