feat(evaluation): add reproducible accessible leaderboard charts

[CurtisBaldwinson]

Description

I came across the AssetOpsBench leaderboard and had a surprisingly hard time telling the model series apart. With several models represented using closely related shades of purple-blue or such (see image below), comparing results at a glance gets difficult pretty quickly.

The mildly amusing part is that IBM has already documented the solution: Carbon recommends categorical palettes for discrete data series, with the sequence chosen specifically for visual differentiation, and its accessibility guidance recommends not relying on color alone.

So rather than just replacing the current chart with a prettier image, this PR fixes the underlying problem: leaderboard figures can now be generated reproducibly from the canonical EvalReport.

What this adds

• Opt-in evaluate --charts generation under <reports-dir>/charts.
• Compact LLM-judge criterion rates derived directly from strict Boolean ScenarioResult.score.details values, excluding missing and non-Boolean values from denominators.
• Deterministic SVG and PNG figures per runner with a report-global model style map.
• Carbon's categorical palette in its documented order, supplemented with contrast-aware hatches, dark outlines, direct percentage labels, and a zero baseline.
• Selectable SVG text plus image semantics and value-bearing descriptions for screen readers.
• Collision-safe filenames and a managed manifest so repeated runs remove only stale generated charts.
• An optional visualization dependency group, keeping Matplotlib out of the default evaluation install.

The historical README image is intentionally unchanged because the repository does not contain a canonical historical EvalReport capable of reproducing its published values. Future leaderboard figures can now be generated directly from evaluation data rather than from hand-maintained percentages or image reconstruction.

No benchmark values or scoring behavior are changed — only the path from evaluation data to pixels.

Type of Change

• New Benchmark Scenario (Industry/Asset type)
• Evaluation Metric / Scorer
• Agentic Orchestration Logic (ReAct, Plan-Execute, etc.)
• Infrastructure / Tooling Improvement

Industry Relevance

Benchmark figures should make differences between models easier to see, not become another part of the benchmark.

For AssetOpsBench in particular, leaderboard comparisons need to remain understandable across larger model sets, runner types, reduced README rendering, grayscale printing, and common color-vision differences.

This change also removes manually maintained visualization data from the future publication path: leaderboard figures can be reproduced from the evaluation system's durable report.

Related Issues

• Refs: N/A

Testing & Validation

• Unit Tests: pytest src/evaluation/tests/test_visualization.py src/evaluation/tests/test_cli.py src/evaluation/tests/test_report.py -q passed, 26 tests.
• Scenario Validation: Ran the real CLI with a synthetic registered llm_judge, once without --charts and once with it. The default run wrote only _aggregate.json; the chart run wrote the aggregate, manifest, SVG, and PNG without a real LLM call.
• Data Integrity: No benchmark data, PII, credentials, or sensitive industrial telemetry is included.
• ruff format --check and ruff check passed for all changed Python files.
• uv lock --check passed.
• Changed-file gitleaks, detect-secrets, and CouchDB data hooks passed.
• Headless sample rendering was visually inspected with seven long model identifiers across two runners. Model styles stayed consistent, hatches remained visible on dark fills, legends did not overlap, labels were readable, and nothing was clipped.
• evaluate --help exposes the new opt-in flag.

The complete evaluation directory currently reports 105 passed and six existing failures in static JSON CAR-metadata tests. Those unchanged tests call an evaluation_metadata argument and expect car_score, but the current origin/main scorer does not implement either behavior. This PR does not modify that scorer or those tests.

Checklist

• My code follows the project's Ruff formatting and linting rules.
• I have performed a self-review of my code.
• I have updated the documentation in /docs accordingly.
• I have signed off my commit (DCO).