I ended up implementing this with a brute force method while pruning the moves I chose next. From any given hand, I calculated the next possible moves that I should make, and searched the move space like a BFS algorithm. I followed the following rules to weed out candidates for the next moves, which make the algorithm run, even for 26 cards, within a few seconds:
Only consider moves in the forward direction (left to right). This works because if you want to move a card or range backwards, you can move a range of cards forwards to achieve the same state.
Cards that must appear in consecutive order in the sorted hand must be moved together. I used a list of list data structure to model this, and only considered moving groups of cards, with the cards in each group being consecutive in the sorted hand. For example in ♦K♠Q9♦7♠A74(...hearts and clubs), the consecutive groups in the first half of the hand are the following 5: ♦K, ♠Q9, ♦7, ♠A, ♠74.
No moves can cause cards of any suit to get unsorted. For example in ♦K♠Q9♦7♠A74 moving ♦K♠Q9 after ♠A is not considered as a next move since the ♦K was moved passed the ♦7, and is now unsorted. My reasoning is that moving everything except the unsorted cards (i.e. 2 ranges on either side of that card) requires at most the same number of moves as moving the entire range and then moving the unsorted cards back. However, I have not proved this.
Only take moves that minimize the number of previously mentioned consecutive card groups. Only the move ♠Q9 after ♠A in the above hands will be considered in the above hand to minimize the number of groups to 2: ♦K♦7, ♠AQ974. My reasoning was that since no cards are being unsorted (rule 3), the most greedy approach should win every time. However I have not proved this.
If a move consisting of a single suit is moved next to other cards with the same suit, do not consider any similar moves in that suit. For example in ♠23456789TJQKA, only ♠2 after ♠3 will be considered as a next move. ♠2 after ♠4 will not be considered due to rule 4. ♠3 after ♠4 will not be considered since all cards moved are in ♠, end up next to other cards in ♠, and another move like this in ♠ had already been considered. My reasoning is that these moves within the suit will have to be made anyway, and there is no point in considering all permutations at every iteration. However I have not proved this. There are also more optimizations in this class of rule (find equivalently good next hands), but I can't think of one that would have a big impact.
Full Java implementation: http://pastebin.com/4eRX2a1w
Here is a run with 13 random cards (also below): http://pastebin.com/fLz4xRAf
level 0, bfs queue size 0
D H D S C D H S D D C S C
J 5 5 Q J 8 2 J K A Q 8 3
level 1, bfs queue size 1
D H D SS D D CC D H S C
J 5 5 QJ K A QJ 8 2 8 3
level 2, bfs queue size 23
SS DD H D D CC D H S C
QJ KJ 5 5 A QJ 8 2 8 3
level 3, bfs queue size 181
DD H D D CC D H SSS C
KJ 5 5 A QJ 8 2 QJ8 3
level 4, bfs queue size 336
DDD H D CC D H SSS C
AKJ 5 5 QJ 8 2 QJ8 3
level 5, bfs queue size 687
DDD D CC D HH SSS C
AKJ 5 QJ 8 52 QJ8 3
level 6, bfs queue size 632
DDDDD CC HH SSS C
AKJ85 QJ 52 QJ8 3
original hand
D H D S C D H S D D C S C
J 5 5 Q J 8 2 J K A Q 8 3
move groups 5 to 7 after group 11
D H D SS D D CC D H S C
J 5 5 QJ K A QJ 8 2 8 3
move groups 1 to 4 after group 5
DD H D SS D CC D H S C
KJ 5 5 QJ A QJ 8 2 8 3
move groups 1 to 4 after group 5
DDD H D SS CC D H S C
AKJ 5 5 QJ QJ 8 2 8 3
move groups 3 to 4 after group 6
DDD H CC DD SS H S C
AKJ 5 QJ 85 QJ 2 8 3
move groups 3 to 5 after group 6
DDD HH CC DD SSS C
AKJ 52 QJ 85 QJ8 3
move groups 2 to 3 after group 5
DDDDD SSS HH CCC
AKJ85 QJ8 52 QJ3
sorted in 6 moves
level 6, bfs queue size 595
Here is a run with 26 random cards: http://pastebin.com/Bw8kzfgU
Here is the run with spades in the reverse order: http://pastebin.com/NwAXavxE