Solution 1
I would "set the permissions 'Access the content overview page' ...", and combine that with using the Rules module to prevent "the Reviewer can modify all contents". Read on for more details about how to do so.
Create a rule (using the Rules module), that is a variation of the rule I included (in export format) in my answer to the question about "How to restrict access to a node via node/12 and allow access via a path like content/sometitle?".
These are the changes to that rule to make it work for this case also:
- Append
/edit
at the end anywhere there is already something like node/%
(I assume when somebody tries to edit a node, they use a node with /edit
at the end, though any variation of that should work in a similar way).
- Add a Rules 'Condition' to verify that the current user trying to do such edit does NOT have role "Editor".
- You probably also need to add another Rules condition like "content is of type" (i.e. 'article' in your case, something that is not mentioned in your original question, but in an extra comment). That way the rules action does NOT apply for ay other content type.
- Change the "Message" (in the Rules 'Action') to something that fits your needs.
- Modify the Rules 'Action' to fit your own requirements, e.g. to issue a redirect to some other page.
Note that the Rules Event is "Drupal Is Initializing" ... Otherwise you are, for sure, "too late": you don't want the rule to be triggered after the edit session has been started already, instead it should be triggered before that. I.e when Drupal is getting ready to start an edit session.
Haven't experimented/tried creating this rule (= variation of the rule in the answer I mentioned above). But pretty sure it'll work.
You may also want to look at my answer to "https://drupal.stackexchange.com/questions/182958/how-to-limit-appearance-settings-based-on-roles-permissions/182959#182959" for another example of a rule, which uses some techniques similar to what you'd need here.
Solution 2
Solution 1 should work, but its weakness is that it's based on "Bypass Content Access Control". Personally I do not like that either. So I agree with your comment about that (a comment which has been removed via moderation). But hey, it's "a" solution to answer "your" (original) question.
If it was up to me to implement a "real" solution for the challenge you're trying to solve, I'd go for a plan b, as further detailed below.
Have a look at my answers to either of these questions:
These answers explain how you can implement a workflow that is pretty (though not exactly) similar to what you are looking for.
To do so, it "only" requires you to use these modules (and regular content types):
And by using such approach, it does not require modules like "Webform" or "Workbench" (modules that are typically involved for these kinds of workfows).
If you're not familiar with Rules, checkout the video tutorials Learn the Rules framework. And/or the similar set of 8 video tutorials about the Flag module.
Note: This "Solution 2" is also how I implemented a variation of your question on 1 of our own sites: it starts from an Issue (= problem or feature request), evolves to a Recipe (= instructions about how to get something to work) and ends with a Software solution (= a plugin or so, whereas the Recipe becomes part of the documentation). Node Convert and Content Access do most of the work for this, and even works in D6 ...