Support weighted eval components and PolyMath difficulty aggregation

[jonabur]

Add configurable component weights so PolyMath contributes its difficulty-weighted score while preserving individual results for inspection.

Status: implemented and awaiting review in draft PR #4. Owner: implementation agent; maintainer reviews the PR. Next action: review the component policy and UI, then merge when accepted. Independent of #2 (overlapping original/multilingual evals).

PolyMath's official per-language score is (low + 2*medium + 4*high + 8*top)/15. The oellm-eval task template emits unweighted per-split mean accuracy; the weighting must happen when combining difficulties. Store relative_weight values (1, 2, 4, 8); divide by their sum to obtain the effective shares (1/15, 2/15, 4/15, 8/15).

Scope and acceptance:

• Optional global catalogue rule identifies components by task match, assigns positive relative weights, and requires the complete configured set within each language/protocol.
• Combine normalized components within language before applying standard or English-balanced aggregation and category weights; preserve behavior for evals without the rule.
• Incompatible aggregation configurations fail validation, including partial or contradictory named-set component/shot selections and invalid component matching. Components inherit common scoring settings. Failed config imports/builds preserve the prior dashboard/output.
• Missing results or duplicate exported components under valid configs warn and exclude the affected group from both comparison scores; retain raw rows for inspection.
• Collapsed breakdowns display calculated scores; expansion exposes individual raw/normalized scores, relative weights, and contributions with explicit units.
• Configuration UI and YAML import/export expose the rule. Delta contributions reconcile to the overall composite.
• Add public tests for validation, weighted arithmetic, language balancing, coverage/exclusions, Python/JS parity and browser behavior. Document the policy and ship PolyMath's 1:2:4:8 weights.

Sources:

• https://qwen-polymath.github.io/#benchmark-score
• https://github.com/QwenLM/PolyMath/blob/main/eval/run_eval.py
• https://github.com/OpenEuroLLM/oellm-eval/blob/8a4b2412a8e8f7f0d95e3845e2164c792add6a79/oellm/resources/custom_lm_eval_tasks/polymath/_default_template_yaml
• https://github.com/OpenEuroLLM/oellm-eval/blob/8a4b2412a8e8f7f0d95e3845e2164c792add6a79/oellm/resources/custom_lm_eval_tasks/polymath/utils.py

Validation at commit 82828aa: 36 Python tests, 99 Node tests, public-fixture and full-export browser suites, and local documentation links passed. PR CI passed, including public tests, browser checks, and shared/demo builds without private exports. No production deployment has been performed; the issue stays open until the PR is accepted and merged.

The relative_weight rename at 4886d35 passed 17 public Python tests, 97 public Node tests, the public browser suite, and CI. Scoring is unchanged; component weight is rejected by schema validation.

Compatibility validation at 05acf0b passed 36 Python tests, 102 Node tests, and both browser suites. Named sets cannot select partial component groups or incompatible shot settings; valid selections with missing CSV results retain the warning/exclusion policy.

Compatibility-check CI passed; deployment was skipped because PR #4 remains draft and unmerged.