Add an authoritative interview solution evaluator

[rosshd]

Parent: #56

Depends on: #45, #47, and the problem-catalog, attempt-lifecycle, and safe-runner children of #56.

Related: #54.

Problem

The current /check flow runs pytest and asks the tutor model to explain the captured output.

Passing a few examples does not establish correctness, optimality, edge-case coverage, complexity understanding, or interview-quality communication.

Raw model feedback can also invent failures, leak reference solutions, or accept unsupported complexity claims.

Goal

Add an authoritative, structured interview-solution evaluator that combines deterministic execution evidence with bounded semantic analysis.

Evaluation stages

1. Validate the attempt workspace and problem revision.
2. Run public and hidden deterministic tests through the safe runner.
3. Classify syntax, compile, runtime, timeout, memory, wrong-answer, nondeterministic, and harness failures separately.
4. Minimize or select a useful counterexample when possible.
5. Analyze the submitted implementation against the problem contract.
6. Evaluate the learner's own time and space complexity explanation.
7. Assess edge-case reasoning, code clarity, and consistency between plan and implementation.
8. Produce structured evidence for the tutor move without directly mutating mastery.

Structured result

Include:

• Correctness status and confidence.
• Deterministic test summary with hidden details redacted appropriately.
• Failure class and smallest safe learner-facing counterexample.
• Observed or reasoned time and space complexity with evidence.
• Difference from the expected complexity target.
• Edge-case omissions.
• Code-quality observations limited to interview-relevant concerns.
• Whether the plan, code, tests, and explanation agree.
• Recommended next move such as debug, explain, optimize, reflect, or transfer.
• Hard flags for evaluator uncertainty, runner failure, or invalid problem data.

Feedback policy

• Do not reveal a full solution before a genuine attempt unless Define repeated-miss progression without false mastery #48 permits a worked example.
• Prefer the smallest diagnostic fact that enables the learner's next attempt.
• Never claim a complexity bound solely because the learner stated it.
• Keep hidden tests and reference implementations out of learner-visible output.
• Treat alternate correct approaches as valid when they satisfy the contract.
• Passing tests is production evidence, not independent mastery.

Acceptance criteria

• Deterministic execution evidence is authoritative over model speculation.
• Runner failures are separated from learner failures.
• Known incorrect solutions fail on validated hidden tests.
• Alternate valid solutions are accepted.
• Counterexamples are reproducible and do not expose the hidden suite.
• Complexity feedback cites relevant code structure or measured evidence and can return unknown.
• Learner complexity explanations are evaluated separately from implementation correctness.
• The tutor receives one bounded recommended move consistent with Enforce concise, single-move tutor responses #47.
• Full-solution leakage and reference-answer copying are covered by regression fixtures.
• Tests cover brute force, optimal, subtly wrong, timeout, mutation, nondeterministic, and runner-failure cases.
• Provider-backed semantic evaluation remains opt-in where deterministic fixtures suffice.
• make check passes.

Out of scope

• Formal verification of arbitrary programs.
• Exact asymptotic inference for every language feature.
• General production-code review.
• Executing untrusted code outside the safe-runner boundary.