AV2: Menuwarp then exitmenuwarp should result in the prior state

[Zannick]

...and thus should be discarded as a duplicate. Presumably our enter area script is changing something.

[Zannick]

Menuwarp, switching menu areas, then exitmenuwarp should also be a duplicate.

[Zannick]

Based on my reading of the debug output, these states are indeed duplicates:

== 87.   Menuwarp to Menu > Upgrade Menu > Physiology ==
position: Giguna__West_Caverns__East_10 → Menu__Upgrade_Menu__Physiology
last: None → Giguna__West_Caverns__East_10
== 88.   Move to Menu > Upgrade Menu > Combat ==
position: Menu__Upgrade_Menu__Physiology → Menu__Upgrade_Menu__Combat
== 89.   ExitMenuwarp to Giguna > West Caverns > East 10 ==
position: Menu__Upgrade_Menu__Combat → Giguna__West_Caverns__East_10
last: Giguna__West_Caverns__East_10 → None
== 90.   Move to Giguna > West Caverns > Small Platform ==

Perhaps this means one of these happened?

1. We never evaluated the state "87. Move to Giguna > West Caverns > Small Platform", which would have made it the best path to the same state after 90.
2. We did evaluate it, but the db merge failed and left us with this as the shortest route.
3. We got something like "89. Collect [...]" as part of a greedy path from prior to 86, and inserted the intermediate states in the queue, but we evaluated the one after 88 (and eventually skipped that Collect) and we never evaluated the one after 86.
4. We got something like "89. Collect [...]" as part of a greedy path from prior to 86 but didn't insert the intermediate state after 86.
5. We got something like "89. Collect [...]" as part of a greedy path from 86 but didn't evaluate "87. Move to Giguna > West Caverns > Small Platform" or record it somehow.
6. We got something like "89. Collect [...]" as part of a greedy path from 87 or later but somehow got to that 87 without also evaluating "87. Move to Giguna > West Caverns > Small Platform" somehow.

Perhaps the correct way to deal with this is to check for duplicate states in the best solutions.

[Zannick]

No, I think that's not quite right, particularly since this solution had two trips to the menu. More likely, this is just pinpoint minimization not being itself minimized, which is odd, because the pinpoint-minimized solution should be recreated in the db after it's inserted, and that should again reach the winning state and extract the solution path from the db.