doctor: diagnose DSH/plugin version skew and current-client compatibility

[Altairpaca]

Why

Current DSH community failures are dominated by upgrade/version skew: plugins can satisfy loose package ranges yet fail at load time after host API changes, and users often discover incompatibility only after Web/runtime composition fails.

DSHelm already has doctor, but compatibility truth must not be reimplemented independently inside the CLI. #34 owns qualification evidence and #47 owns the shared machine-readable Compatibility Radar projection. This issue should make doctor a consumer of that projection plus local installed-package observations.

Scope

• Consume the compatibility status/projection defined by feat: expose a machine-readable DSH Compatibility Radar #47 rather than maintaining a separate verified/candidate truth table.
• Inspect locally installed DSH/package metadata without network calls or profile mutation.
• Compare the installed DSH CLI/package cohort with the verified baseline and current candidate represented by feat: expose a machine-readable DSH Compatibility Radar #47.
• Distinguish at least: verified, candidate-unverified, blocked, newer/unknown, older/unknown, and mixed-package-graph where detectable.
• Report actionable detail when the installed host/client generation differs from the DSHelm evidence contract.
• Detect legacy rc.7 client composition versus the current modules/renderer/session generation where local package metadata is available.
• Name conflicting package/version rows in a mixed cohort instead of returning a generic PARTIAL state.
• Keep compatibility status separate from provider authentication, model-quality evidence and the existing keyless synthetic runtime probe.
• Include an actionable next command or evidence request when the state is candidate/unknown/mixed.
• Preserve a machine-readable doctor result for tests/automation, but derive compatibility fields from feat: expose a machine-readable DSH Compatibility Radar #47.

Example output shape

DSH compatibility   CANDIDATE_UNVERIFIED
installed           0.1.5-rc.1
verified             0.1.0-rc.7
candidate            0.1.5-rc.1
source/API           PASS
package graph        FAIL|PENDING
web/runtime          PENDING
next                 run/report candidate compatibility journey

Exact CLI wording may change; the evidence distinction may not.

Acceptance

• A verified rc.7 fixture reports verified because the shared compatibility contract says so.
• A 0.1.5-rc.1 fixture reports candidate-unverified until compat: audit and qualify DSH 0.1.5-rc.1 without widening the verified baseline #34 evidence is promoted through feat: expose a machine-readable DSH Compatibility Radar #47.
• A failed candidate layer remains visible even if source compatibility is green.
• A mixed host/client package fixture reports the conflicting package names/versions.
• An unknown newer DSH release fails open for diagnostics but never reports verified compatibility.
• Existing keyless runtime probe remains independent: a passing synthetic probe cannot override a version-skew warning.
• CLI and Compatibility Card cannot disagree because they consume the same projection.

Related: #8 #32 #34 #47.