evals: resolve the EvalCase parameter statically, not by value scan

[renaudcepre]

What

Closes #120 — addresses it structurally rather than with a runtime backstop (per discussion).

The design problem

The wrapper had two sources of truth for "which parameter carries the case":

Moment	Mechanism
Registration	reads type hints (_validate_single_evalcase_param)
Runtime	scans values (_find_case, isinstance(v, EvalCase))

They could disagree. A parameter not annotated as EvalCase whose fixture returns one at runtime (e.g. Annotated[Database, Use(db)]) was invisible to the registration guard but visible to the value scan — which then silently picked whichever EvalCase came first in kwargs order, misattributing its name/expected/inputs.

The information was already known statically: the case is injected by the DI layer under a specific parameter name. The runtime didn't need to rediscover it by value.

Change

Resolve which parameter carries the case once, at decoration time (_resolve_case_param), and do a direct kwargs[name] lookup at runtime. A parameter qualifies as the case when:

• its declared type is an EvalCase (subclass) — case: EvalCase, Annotated[EvalCase, From(cases)]; or
• it is bound via From(source) whose source yields EvalCase instances — covers the deliberately loose Annotated[Any, From(cases)] form.

More than one qualifying parameter still raises MultipleEvalCaseParamsError at registration.

This collapses the registration guard, the runtime guard, and the value scan into one static source of truth: the case is identified by which parameter it is. An EvalCase merely returned on an unrelated parameter can no longer be mistaken for the case — issue #120 becomes structurally impossible instead of guarded-against.

Removes _find_case, the _extract_* value scanners, and _validate_single_evalcase_param.

Tests

tests/evals/test_multiple_evalcase_params.py rewritten around the new contract:

• typed / subclass / loose-From case params accepted;
• two qualifying params (incl. typed + loose-From) rejected at registration;
• an EvalCase returned on an unrelated parameter is ignored, not misattributed;
• a From over non-EvalCase items (e.g. dicts) is parametrization, not a case (falls back to the function name).

Full suite: 1246 passed, ruff clean, mypy --strict clean.