feat: Grader plugin extensibility (WASM/external programs)

[spboyer]

Migrated from spboyer/waza#390

Summary

Design how custom graders beyond config-driven types can be distributed via the registry.

Context

From waza-vs-openai-evals.md Row 15: OpenAI Evals allows Python class inheritance for custom eval logic. Waza is config-driven only (code, program graders). This is waza's #2 competitive gap.

Options

1. WASM plugins — compile grader logic to WASM, distribute via registry. Sandboxed, cross-platform.
2. External program protocol — any binary that accepts stdin JSON and outputs grader results. Already partially supported via program grader.
3. Go plugin interface — plugin.Open() for native Go graders. Fast but platform-specific.
4. Embedded scripting — extend code grader beyond Python (JavaScript, Lua, Starlark).

Parent: #385

[spboyer]

Audit note: this is partially covered by the existing program grader and inline script grader, which already allow external validation logic to run outside the built-in config-only graders. The remaining gap is the plugin distribution model described here: registry integration, WASM or external plugin packaging, versioning, and lifecycle behavior.

[spboyer]

Follow-up plan from issue audit

External grader execution is partially covered by the existing program grader and inline script grader, but registry-distributed plugins and WASM/extensibility are not implemented.

Missing items

• Decide the first plugin distribution format: WASM, external executable package, or both.
• Define a stable grader plugin protocol: inputs, outputs, scoring, diagnostics, timeout, and workspace access.
• Define registry metadata for plugin graders, including versioning, checksums, and runtime requirements.
• Implement resolution/cache/install behavior for plugin grader references.
• Add safety documentation for executing third-party graders.
• Add tests with at least one sample plugin grader and one failure-path fixture.