This usually happens when a project has been edited by two different computers while one of them was offline. When it goes back online it has a list of changes to upload, but Dropbox notices that these same files have already been altered on the server, and so it produces conflict copies to let you sort it out. In a normal scenario this is obvious, but in Scrivener with everything hidden, it can go completely unnoticed. That might not be precisely what happened in your case; with all of the hardware and crashing problems, it could be another factor, but either way here is how to go about fixing it.
The best way to check is not to try and compare each file individually, but to create two copies of the project in Finder (so you have three total). Name one “Jayne” and the other whatever else you want. In the Jayne one, go with all of the copies labelled likewise by deleting the primary copy and renaming the Jayne copies so they no longer have the parenthetical. In the other project copy, just delete the parenthetical copies.
You asked if anything else should be checked: yes. Just go through every single folder and look for conflicted copies. In some cases (like the Snapshots folder) you’ll find List View in the Finder to be the most useful as you can expand several hundred folders at once and quickly scroll through the list.
Now open both projects side by side in Scrivener. If one malfunctions in any way (produces _Recovered Files in the binder or just flat out refuses to open), then your choice is easy. Stick with the one that doesn’t. 
Recovered files happen when the binder doesn’t have instructions for files that exist in the project. Say you add a text file to the binder, but then revert back to a copy of the binder that pre-dates that addition, the text file is now an orphan and the binder doesn’t know what to do with it, so it collects it and any other orphans into the recovered files folder in the binder when you open the project.
The second thing to look for is something only your brain can do: look for any structural or meta-data type disparities and figure out which one is the best copy—or the closest to best and then manually merge the changes from the other project into it. You’ll want to do this even if one produces Recovered Files and the other doesn’t. Just remember both of these represent two different “forks” of work. You did something in both of these copies. The trick is remembering and finding what you did. In your case, given the list of conflicted copies you pasted, it’s likely you did make content changes. The search index file has been forked, which makes it likely there are content level conflicts, not just binder structure and meta-data conflicts. So definitely scan through the Files/Docs folder as well. The search index also records binder titles and such, so it doesn’t necessarily mean there are content forks, it just makes it more likely.
The .scrivx file is plain-text human readable XML, so it would be possible to use FileMerge or another diff utility to scan for changes. This would be more of a fact-finding task. I wouldn’t recommend trying to merge the XML files by hand as that requires a lot of omniscience to do correctly. Just use it as a reference for where to look in the two binder copies.
Unlikely. If there isn’t a conflict copy, that means Dropbox was never confused, and that means the content should be identical in both forks.
What do you need to check for are files that don’t exist in one fork. If you added files or folders. If you can’t find a way to integrate the new files back in easily. I would consider just importing them as files into the project you are using as your new master project.
What I would do is this: once you find and/or merge a corrected .scriv copy from one of the duplicates, use it to replace the current one in Dropbox entirely. I’d back the current one up and call it something obvious so you know it was the last backup you made before merging things.
This way if you come across any problems a week or two from now, you’ll have everything you need to salvage the problem in that backup.
Here is your checklist. If you follow that to the letter in all cases, you should avoid this problem entirely. I would add one more to that list, the corollary to #2: wait for Dropbox to finish syncing before sleeping or shutting down the computer.