docs: record Harness evolution roadmap

[dengmengmian]

Summary

Adds a durable Harness-specific roadmap so future work does not conflate completed Browser/runtime work with the evidence-gated SubAgent/extension path.

What changed

• add docs/HARNESS_EVOLUTION_PLAN.md as the single source of truth for Harness evolution;
• record the current Batch feat(webui): themes, inline DiffViewer, run status (+windows build fix) #1 gate and R001-R010 pressure/spawn intent;
• compare DeepSeek Harness with CodeLeveler and explicitly separate adopt / defer / reject decisions;
• define the post-Batch sequence: Harness foundation → Spawn Utility decision → Spawn Reliability Gate → Structured Child Result → Capability Profile → Capability Negotiation → SubAgent Provider Seam → optional continuable child → constrained Capability/Extension framework → Durable Multi-Agent Runtime;
• explicitly state Browser Capability V1 is complete/merged at the f610d1d snapshot and must not reappear as roadmap work;
• explicitly reject Cordis / Everything is a Plugin for the Runtime Kernel, Engine/safety pluginization, and a second SubAgent runtime/state machine;
• link the shipped multi-agent.md behavior to the future evidence-gated roadmap without changing product semantics.

Why

The Runtime roadmap and Harness roadmap answer different questions. This document keeps the stable Runtime Kernel authoritative while making the Harness composability path explicit and evidence-driven.

Validation

Docs-only change. Compared against main@f610d1d; branch is ahead by two documentation commits and does not modify product code.