There isn't a precondition that can enforce that kind of policy. There are external code review systems that might provide the integration you want for that kind of policy. SmartBear is one of them. Someone recently posted about a ReviewBoard integration. I don't know much about either but it's worth checking out.

There are other preconditions that might provide an acceptable work flow. You can look at the "Prevent Linking to Approved Work Items" precondition and split your work items so that change sets associated with a work item are reviewed by one person. It requires more micromanagement with your work items but you can stop developers from attaching change sets to work items that have already been approved. Any approvers must review all change sets attached and reject the approval if there are change sets they aren't supposed to review.

I do not believe project/team configuration provides that level of granularity out of the box. But, you can add X number of required approvers where X is the maximum number of change sets associated with a work item. Of course, this will require predicting how many change sets will be added to the work items.

To provide an exact solution to your problem, you would need to write your own process advisor which will return false upon deliver (hence failing the deliver op) if number of change sets are more than the number of approvals. It is still not possible, in my opinion to relate which approval is for which change set. Feel free to submit an enhancement request.