After some additional thought, I think that explicit listener methods for these events is the right approach. It is more consistent with existing events, and, more importantly, these events are not redundant - they simply represent a different use case.
For example: ListView selection listeners must currently listen for selectedRangesChanged() even when the list is in single-select mode. A selectedItemChanged() event would probably make a lot more sense to those callers, since multiple ranges will never be selected.
Another (existing) example is TextInputTextListener - this interface contains an ostensibly redundant textChanged() method that is called any time the text input's text changes. Callers could listen for charactersInserted() and charactersRemoved() directly, but this wouldn't be as convenient. The selectedRangesChanged() event in ListViewSelectionListener and TableViewSelectionListener behaves similarly.
Given that there are existing similar examples, and that tying selectedItemChanged() directly to selectedIndexChanged() would result in spurious events (when the selected index changes indirectly due to a model change), I think I would recommend not using an annotation here.