cycle() is defined on the Iterator trait, not on ChunksMut. As for why it is there - well, because for most cases there's a sensible default implementation in terms of next and clone, and there's no need to duplicate it on every iterator possible.
I think the question here might by why the compiler complains about "trait bounds not satisfied" instead of "no method named 'cycle' found".
But I'm not sure, maybe that interpretation is totally off.
In any case, the answer to this question is: the compiler doesn't really have an understanding that implementing Clone for ChunksMut is neither something you can do nor something the standard library will ever do. There are comparable scenarios where the missing bound can be added by you or at least could be added upstream in the future. In such a setting, the cycle method might magically appear out of nowhere if it was previously considered not a method on ChunksMut at all; methods suddenly appearing like that seems undesirable, so it's better that it just is a method that exists in the first place, even if it's entirely uncallable, because the trait bounds can't ever be fulfilled.
That's hard to do in general, since compiler can't prove that such interleaved mutable references won't collide, and their collision is prohibited by Iterator interface.