feat(eval): task-set schema and loader — Step 1 (#1514)

[Lexus2016]

Summary

Implements Step 1 of the eval harness (issue #1514, parent #1481).

Changes

• EvalTask dataclass — frozen, with fields: id, prompt, expected_tools, expected_result_pattern (optional regex), category, difficulty, version, notes
• v1.0 task set — 8 tasks across 4 categories: code (2), search (2), file_ops (2), reasoning (2)
• Versioning — _TASK_SETS registry, list_versions(), latest_version()
• load_task_set(version) — loader returning tasks for a version (defaults to latest); raises ValueError for unknown versions
• Helper functions — task_count(), categories(), difficulties()

Design

• Pure data layer — no network, no execution. The runner (Step 2, [Eval Harness] Step 2: Agent runner — execute task, capture full trajectory #1515) and null-agent baseline + scoring (Steps 3-4, [Eval Harness] Step 3-4: Null-agent baseline + run baseline, output scores.jsonl #1516) are separate issues.
• EvalTask is frozen (immutable) for safe sharing across test runs.
• compiled_pattern() returns case-insensitive compiled regex or None.
• load_task_set() returns a copy of the list so callers can't mutate the registry.

Test plan

• 24 unit tests (tests/scripts/test_eval_tasks.py) — all pass
• Tests cover: schema fields/defaults, compiled_pattern(), versioning, loader, v1.0 requirements (5-10 tasks, ≥3 categories, unique IDs, version consistency)
• No external dependencies — import-safe and fast

Requirements met (from issue #1514)

• ✅ EvalTask schema with id, prompt, expected_tools, expected_result_pattern, category, difficulty
• ✅ 5-10 tasks (8 tasks)
• ✅ ≥3 tool categories (4 categories: code, search, file_ops, reasoning)
• ✅ Versioning (v1.0, extensible registry)
• ✅ load_task_set() loader

Closes #1514

[Lexus2016]

Blocked at code-review (autonomous evolution-integration): DEAD CODE.

scripts/eval_tasks.py is imported ONLY by tests/scripts/test_eval_tasks.py — there are zero call sites in the live tree. grep -rn 'eval_tasks\|load_task_set\|EvalTask' . --include='*.py' (excluding the module + its test) returns nothing. This matches the dead-code pattern the integration gate rejects (a green-CI module nothing imports).

The idea (issue #1514) is sound — this is Step 1 of a decomposed roadmap and a data-layer-only PR is a legitimate decomposition choice. But a module with no consumer is not mergeable on its own: it cannot be exercised and provides no behavior. Sending the issue back for rework with a concrete integration requirement — see the comment on #1514.

Closing this PR (its branch is a dead end); the next implementation run will rebuild against the rework brief.