Good idea, in the most simplistic terms you want the violation browser to report based on cell type rather than instance name.
But researching remaining nanoRoute violations will only tell you when your library is problematic not when it is sub-optimal.
One of your cells has an output pin that is only accessible from the north direction in M1 stub and a single cut via.
If nanoRoute completes cleanly ( and by default it will try very hard for a very long time to succeed ) you would never know there is an sub-optimal cell.
Optimal standard cell libraries will only help routability which can dramatically improve run times for routeDesign and optDesign -postRoute -SI.
I cannot think of a simple testcase that would check, all pins, in all cell orientations, from all directions, for multi cut vias and M1 stub access.
You could possibly use your current layout and back off the repair effort level and sort through the lower metal level errors.
Your best bet maybe to write a custom DRC rule deck to check standard cell optimization .
Most of the online documentation I have found has to to with routing rules & guidelines.
Has anyone found any Cadence documentation / software for optimal standard cell library layout?