Add eval scenarios that exercise the Service and PVC diagnostic contracts

[hellices]

Problem

No bundled scenario exercises diagnose_service or diagnose_pvc:

두 도구를 증거 경로로 선언한 시나리오: 없음

The 23-scenario pack grades ordinary get_resource / get_events / diagnose_pod paths. Nothing puts a model in a situation the two deterministic tools were built for.

#176 plans a matched baseline-versus-diagnostic comparison to decide whether those tools are worth keeping. Without scenarios covering their contracts, that comparison has almost nothing to measure.

What is already fixed

The related grader defects are closed by #219, which is a useful floor:

• identity arguments (service, pvc) fold onto name, so a model using either tool is credited for the evidence it fetched;
• diagnose_service implies {services, endpoints, endpointslices}, so it satisfies the existing Service scenario's kind: endpoints evidence — verified on main.

So the harness can now measure a model that reaches for these tools on the existing pack. What is missing is scenarios that make reaching for them the right move, and that cover the states the analyzers actually distinguish.

Scope

Add scenarios covering the two contracts, per #176's list:

Service — ready endpoints; matching slices with none ready; no slices at all; stale slices; an RBAC-denied EndpointSlice read producing an explicit evidence gap. Include a healthy control. Do not credit a selector-mismatch conclusion unless both the selector and the pod labels were observed.

PVC — Bound; Lost; Pending with a provisioning-failure event; named StorageClass missing; no default class; multiple defaults; WaitForFirstConsumer; static/pre-bound; an RBAC-denied StorageClass read.

Constraints

• Evidence must stay route-agnostic. Express expected evidence as the fact and its target, not as "you must call diagnose_service". A baseline run without the diagnostic tools has to be able to satisfy the same evidence through ordinary reads, or the comparison measures tool availability instead of diagnosis quality.
• The Service fixtures currently seed legacy Endpoints while diagnose_service reads EndpointSlice. New Service scenarios should seed EndpointSlice; whether to also keep Endpoints for the legacy read path is a judgement call worth making explicitly.
• test_bundled_evidence_is_reachable_through_the_real_tools must keep passing — every declared evidence item has to be genuinely fetchable from the fixture.

Acceptance criteria

• Each analyzer contract has positive, negative, ambiguous, and RBAC-denied coverage.
• Every new scenario declares evidence reachable through ordinary read tools as well as the diagnostic route.
• The healthy controls do not reward inventing a fault.
• Local/on-prem agent quality: conversational AKS exploration eval, model scoreboard, prompt/tool tuning, and AKS matrix #176 can run baseline-versus-diagnostic arms that differ only in the offered tool set.

Context: #176, #191 (closed), #213, #216, #219, #221.

[hellices]

Delivered in #227 (8460976).

What landed

Two scenarios covering the contracts the analyzers were written for:

• service-endpoints-not-ready — a matching EndpointSlice exists and its endpoint is unready behind a 503 readiness probe. Distinct from the existing selector-mismatch case, where no endpoint matches at all; this is the state service.no_ready_endpoints distinguishes.
• pvc-wait-for-first-consumer — a negative control. Pending is correct under WaitForFirstConsumer, so a model reporting a provisioning fault has over-diagnosed. This is the case most likely to produce a confidently wrong answer, which is why it was the first PVC state added.

builtin_aliases() gained EndpointSlice, without which a baseline arm could not read the slice at all — list_resources(kind=endpointslices) returned unknown kind.

Route-agnostic, and enforced

test_diagnostic_scenarios_are_gradeable_without_the_diagnostic_tools asserts every evidence group is satisfiable through ordinary reads. Without it a baseline arm would fail by construction and #176's comparison would measure tool availability rather than diagnosis quality.

The grader bug this surfaced

Validating the keywords against realistic phrasings — rather than assuming they worked — found a defect affecting the whole 23-scenario pack: _CLAUSE_SPLIT did not treat dashes as clause boundaries, so a negator carried to the end of the sentence.

answer	before
...was not restarted by the operator — it was OOMKilled with exit code 137.	FAIL
identical sentence with a full stop	PASS

Models punctuate with dashes constantly, so this understated every model measured, including the scoreboard rows already published on #176.

What was not obvious

The first draft rejected 2 of 5 correct phrasings, and three review rounds each found one more instance of the same trap: a keyword list written for a diagnosis whose correct answer is itself negative. Required keywords get suppressed by earlier negators; forbidden keywords match token runs, so no endpoints fires on the correct "no endpoints are ready" and no storage class on "no storage class problem".

The phrasings are now pinned in _GRADING_CASES rather than eyeballed, and the pattern is recorded in docs/dev/agent-decisions.md so the next scenario author does not rediscover it.

Remaining scope, deliberately not done here

This covers one state per contract, not the full matrices listed above (stale slices, RBAC-denied reads, Bound/Lost, provisioning-failure events, missing/multiple defaults, static provisioning). Those are worth adding as #176's comparison shows which distinctions actually matter — adding twelve more fixtures before the first measurement would repeat the mistake #191 was closed for.

Closing: the blocking gap — that no scenario exercised either tool — is gone, and #176 can now run its matched arms.