feat: bridge DSH 0.1.2 APIs and redesign the project landing page

[Altairpaca]

Why

DeepSeek Harness released dsh-v0.1.2-rc.1 on 2026-09-03. DSHelm's verified install baseline is still 0.1.0-rc.7, and the upstream train changes several seams DSHelm touches directly. At the same time, the repository landing page needed to communicate mechanism, evidence and compatibility status visually rather than as a long feature list.

This PR prepares the source for the current DSH train without pretending that the new npm package graph has already been verified.

DSH 0.1.2 source compatibility

Session log

• add snapshotSessionLog() as a structural compatibility bridge;
• prefer the 0.1.2 snapshotEvents() API;
• fall back to the verified 0.1.0-rc.x events getter;
• fail loud on an unknown session surface;
• route runRoleAgent() final-assistant extraction through that bridge.

Subagent selection

• advertise the new SubagentCapabilities.agentOptions flag at runtime while remaining compilable against the pinned legacy type surface;
• carry DSHelm's resolved reasoning into the new AgentOptions.reasoningEffort field for current hosts;
• retain the request/header seed as the legacy reasoning path so the verified rc.7 baseline is not silently weakened.

Browser client source

The 0.1.2 source tree no longer contains the old packages/client/runtime / @deepseek-ai/dsh-client-runtime package. @deepseek-ai/dsh-client-modules@0.1.2-rc.1 now owns dsh.client scanning, boot-graph composition, /plugins bundle delivery and lazy materialization.

• remove the browser source import from @deepseek-ai/dsh-client-runtime/client;
• type only the sessions.binding(...).session.projections.faceOf(...) structure DSHelm actually consumes;
• correctly dispose the active projection subscription when the selected session changes (the old code did not retain that cleanup).

Important: packages/dsh/package.json still depends on/injects the legacy client runtime because changing the package graph without regenerating pnpm-lock.yaml would invalidate the verified install baseline. Exact package/client graph promotion is tracked separately in #20 and must happen atomically with the lockfile and Web-load evidence.

Compatibility evidence

• keep compatibility.json.tested.dshPackages = 0.1.0-rc.7;
• add target.dshRelease = 0.1.2-rc.1, exact tag/source commit/date, audited seams and explicit promotion blockers;
• add docs/compatibility/dsh-0.1.2-rc.1.md with a seam-by-seam audit and repeatable future-release checklist;
• add regression coverage for both Session API generations and the new subagent capability;
• include the compatibility bridge test in the normal DSH CI lane.

README / visual redesign

The bilingual landing pages are rebuilt around a visual narrative instead of a feature dump:

1. redesigned hero showing Task → Policy → Evidence and planner/worker/reviewer routing;
2. compatibility status card separating DSHelm source status, verified DSH install baseline, and current source target;
3. routing-flow diagram showing hard gates → evidence → policy overrides → DSH execution → Resolution Trace;
4. retained real control-plane screenshot as product evidence rather than replacing it with diagrams;
5. explicit DSHelm-vs-DSH ownership table;
6. credential-free first-run evidence table;
7. current capability/evidence matrix;
8. detailed DSH 0.1.2 compatibility section with the client-module blocker surfaced near the top.

The docs checker now treats the hero, routing flow, compatibility card, real screenshot, bilingual version/evidence facts, and non-region-priority positioning as maintained community contracts.

Evidence boundary

This PR does not claim verified 0.1.2-rc.1 package compatibility and does not bump DSH manifests or the lockfile. Promotion requires the complete candidate npm graph, current client-module composition, fresh packed install, isolated profile boot, Web bundle materialization and the usual doctor/explain/fixture/uninstall evidence.

Refs #7, #20