feat: expose a machine-readable DSH Compatibility Radar

[Altairpaca]

Problem

The DSH plugin ecosystem is moving quickly enough that typecheck/unit-test success is not sufficient evidence of compatibility. Real failures can appear at package resolution, Cordis composition, Web client materialization, runtime lifecycle, native install scripts or clean-profile boot.

DSHelm already tracks these boundaries internally through compatibility.json, compatibility-candidates.json, compatibility-evidence.json, #34 and the candidate CI lane. That evidence should become a small public product surface rather than remain maintainer-only CI state.

Community context:

• 有没有人搞过升级 dsh 插件代码来支持新 dsh 版本的 skill？ deepseek-ai/deepseek-harness#5120

Product contract

Expose compatibility as evidence by layer, not as one broad supports DSH 0.1.x boolean.

At minimum a host/candidate should be representable as:

DSH 0.1.0-rc.7   VERIFIED
DSH 0.1.5-rc.1   CANDIDATE

source/API        PASS
package graph     FAIL|PASS|PENDING
packed install    PASS|PENDING
clean profile     PASS|PENDING
session lifecycle PASS|PENDING
web client        PASS|PENDING
runtime journey   PASS|PENDING

Scope

• Define a stable JSON projection derived from the existing compatibility candidate/evidence contracts.
• Preserve evidence layer, status, target version, source/commit where applicable, observed time and blocker detail.
• Distinguish verified, candidate, blocked, unknown/newer, and mixed-cohort states.
• Make the projection consumable by dshelm doctor / doctor: diagnose DSH/plugin version skew and current-client compatibility #41 without duplicating compatibility logic.
• Add a compact human-readable Compatibility Card for README/release notes/control-plane use.
• Keep source/API PASS distinct from package/runtime/Web verification.
• Make stale evidence visible instead of silently carrying it forward when the DSH candidate changes.
• Provide fixture coverage proving a candidate cannot render as verified until the machine promotion contract passes.
• Document the schema so plugin indexes/marketplaces can consume it later without scraping README text.

Acceptance

• 0.1.0-rc.7 can render as verified only because it is the current checked-in verified baseline.
• 0.1.5-rc.1 remains candidate while compat: audit and qualify DSH 0.1.5-rc.1 without widening the verified baseline #34/ci: qualify DSH 0.1.5 candidate source graph in isolation #45 have incomplete or failing checks.
• A failed candidate-source/package check is visible without downgrading the verified baseline.
• An unknown newer host is diagnosable but never implicitly marked compatible.
• A mixed package cohort names the conflicting packages/versions when locally detectable.
• The same underlying projection can feed CLI diagnostics and public compatibility presentation.

Non-goals

• an autonomous plugin migration bot;
• claiming compatibility from semver ranges alone;
• remote telemetry or phoning home from doctor;
• replacing the broader DSH community upgrade-skill efforts.

This is the public/easily consumable layer above #34 and #41. It should turn DSHelm's compatibility discipline into reusable ecosystem infrastructure rather than another private CI convention.

Related: #32 #34 #41 #45