Design the capability and evidence contract for diagnostics (#409) #484

Problem

#409 asks for a shared capability and evidence contract before #410, #411 and the later diagnostics are built. That needs design decisions that every consumer will inherit:

• the state vocabulary for evidence sources;
• how failures are classified;
• what a diagnostic may conclude from incomplete evidence;
• how API versions are chosen without server-version gates;
• how observations are scoped and invalidated across context changes;
• how the Kubernetes support policy is set.

Today three models describe the same idea differently: Pulse coverage, relationship-graph coverage, and the outcome tracker's partial evidence. Discovery failures are only logged. can_i is fail-open. Nothing documents which Kubernetes versions are supported.

Goal

A design spec under docs/superpowers/specs/ that the maintainer reviews before any implementation. It should cover:

• the units and the layer each lives in;
• the vocabulary and the classification table;
• the combining rules;
• version resolution;
• bounded collection;
• scoping and caching;
• the presentation contract;
• the support-policy proposal;
• testing, and the delivery slices that become their own sub-issues.

Done when

• The spec is merged, with its open decisions confirmed or changed in review.
• Each delivery slice it lists has a sub-issue under Add capability-aware diagnostics with explicit older-cluster fallbacks #409.