docs: refocus community roadmap on runtime truth and compatibility

[Altairpaca]

Why

The August community roadmap still framed success mainly as publishing an alpha and then observing adoption. Current DSH community evidence is more specific: users/plugin authors are struggling with effective route visibility and upgrade/runtime compatibility, while raw plugin count is already abundant.

Change

• make Effective Route Truth + Compatibility + Explainability the explicit DSHelm product thesis;
• separate requested → resolved → effective route semantics;
• separate source/API → package graph → packed install → clean profile → Session → Web → runtime compatibility evidence;
• align execution order with 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, feat: ship Effective Route Inspector and escalation guard #46, feat: expose a machine-readable DSH Compatibility Radar #47/doctor: diagnose DSH/plugin version skew and current-client compatibility #41, then release: publish npm alpha and verify clean-HOME install/uninstall #7/community: problem-led public alpha launch and adoption evidence #23, then higher-level routing policy feat: introduce evidence-conditioned routing policy with runtime-route guardrails #31;
• define the first two problem-led technical community artifacts around DSH plugin upgrades and root/subagent route divergence;
• replace star-count goals with adoption evidence: external install reports, route cases, contributor PRs and ecosystem references;
• provide equivalent Chinese and English roadmap documents so the public product/evidence boundary is not language-dependent;
• preserve existing independence, privacy and non-Chinese-first guardrails.

Scope

Documentation/roadmap only. No runtime, compatibility baseline, package graph, routing score or release behavior changes.

Related: #23 #31 #32 #34 #41 #45 #46 #47.