There's only so much customization you can do in editworkflow.cgi, because RESOLVED much be reachable from any other status (because when it is marked as a duplicate, for instance, it becomes RESOLVED). The workflow itself doesn't consider the history of the bug.
If you really wanted to enforce this sort of business logic, you should start diving into process_bug.cgi. If someone want to set the status to FOO but it needs to have been in status BAR before, you could check the bug's history in bugs_activity.
But that's a lot of work, and you're likely to have special cases, more rules, more special cases, etc.
I think you would be better off identifying bugs that didn't go through the proper workflow after the fact. When you identify such a bug, you would reopen them or put them into whatever status.
You would do this by examining bugs_activity to see what values of bug_status have been added/removed.