feat(mcp_readability): group style findings per tool

[akangsha7]

Summary

Style-judge feedback was organized by severity, with a single finding carrying a comma-joined tool list ("tool": "get_cluster, list_clusters"). A reviewer fixing one tool had to scan every severity bucket and work out which findings applied to it.

The judge now returns its findings already grouped by tool, so the scorer parses that grouping rather than reconstructing it:

"findings_by_tool": [
  {"tool": "general", "findings": [{"severity": "P0", "rule_id": "Tool Count Limits", ...}]},
  {"tool": "get_cluster", "findings": [{"severity": "P0", ...}, {"severity": "P2", ...}]}
]

• Prompt: one entry per tool, findings ordered P0 -> P1 -> P2 within an entry, and a violation affecting several tools reported under each with wording specific to that tool (its own parameters, description). A general entry covers issues tied to no single tool — the server exceeding the 40-tool limit, a missing LRO polling tool, a parameter named inconsistently across tools.
• Parsing: _clean_findings_by_tool only drops entries that can't be rendered (no tool name, findings not a list). Entry and finding order are the judge's.
• Feedback HTML: one findings list per tool, headed by that tool's severity tally (get_cluster — 1 P0, 1 P2).
• Counts: p0/p1/p2_issues count distinct rules violated rather than finding occurrences. Without this, one finding per tool would score a 40-tool surface far worse than a 4-tool one for the same design mistake, and would swing with how many tools the judge attributed a rule to.

Test plan

• cd evalbench && uv run pytest test -q -k mcp — 109 passed
• One live judge run against a real endpoint to confirm the model returns the nested shape; unit tests cover parsing and rendering but not the model's behavior