compat: qualify DSH 0.1.7-rc.1 and migrate Session V4 evidence seams

[Altairpaca]

Context

DeepSeek Harness published dsh-v0.1.7-rc.1 on 2026-09-23. DSHelm's verified install baseline remains @deepseek-ai/dsh@0.1.0-rc.7; the current forward-qualification work in #34/#45 is still pinned to 0.1.5-rc.1.

The 0.1.7 candidate changes several seams DSHelm now treats as evidence-bearing contracts, so the new train needs a fresh qualification boundary instead of inheriting 0.1.5 assumptions.

Upstream changes that directly affect DSHelm

• Session logs advance to V4, with migration support from earlier formats.
• Synchronous Session history reads snapshotEvents, eventAt, and ownEvents are deprecated.
• agent/session-start becomes the async, serial agent/created lifecycle event; the first model request waits for initialization.
• Client Session supports multiple instances and related client APIs / slots change.
• Profile/plugin settings ownership changes; legacy settings migration is one-time.
• Plugin installation/startup now performs DSH-version compatibility checks.
• PTC package/service naming changes and some old names are no longer compatible.

These changes are release-note facts; they are not yet DSHelm compatibility claims.

Qualification work

Durable runtime evidence

• Audit the replacement for DSHelm's snapshotSessionLog() path. fix(dsh): bridge current Session snapshots without dropping rc.7 #40 intentionally preferred snapshotEvents() for the 0.1.5 generation; 0.1.7 now deprecates that synchronous surface.
• Keep request/header evidence used by feat(dsh): capture effective route from durable request evidence #50 observable from the supported Session V4 history API.
• Verify reconnect/replay preserves historical effective-route observations and does not fall back to inferred resolved state.
• Add a Session V4 fixture covering request/header extraction and final-assistant/event reads.

Agent lifecycle

• Audit DSHelm initialization hooks against async serial agent/created.
• Verify the first model request cannot race DSHelm policy/settings/evidence initialization.
• Re-run root/child effective-route fixtures from feat: ship Effective Route Inspector and escalation guard #46 against the new lifecycle.

Client / Web / settings

• Audit the current Control Plane client projection against 0.1.7 multi-instance Session and slot APIs.
• Verify the DSHelm client bundle is discovered/materialized in a real 0.1.7 Web profile.
• Audit installDSHelmSettings() against the current Profile/plugin configuration ownership and hot-update semantics.

Package and distribution gates

• Replace the stale 0.1.5 candidate source lane with an exact 0.1.7-rc.1 candidate cohort.
• Keep candidate resolution isolated from compatibility.json.tested.
• Run typecheck/build and compatibility-sensitive tests against the candidate graph.
• Pack/install DSHelm artifacts into a fresh consumer.
• Run isolated HOME/DSH_HOME init, bounded boot, doctor, explain, first-run and uninstall.
• Record machine-readable layer results for feat: expose a machine-readable DSH Compatibility Radar #47; doctor: diagnose DSH/plugin version skew and current-client compatibility #41 should consume that shared result.

Relationship to existing 0.1.5 work

#34/#45 remain useful historical evidence for the 0.1.5 API transition, especially Session V3, Agent/Inbox and current-panel adaptations. They should not be promoted as the current forward target now that 0.1.7-rc.1 is the latest release candidate.

Any reusable source changes from #45 should be carried forward deliberately; the old candidate version should not be merged into compatibility metadata merely to make the stale lane green.

Evidence boundary

Do not change compatibility.json.tested.dshPackages = 0.1.0-rc.7 until the full package, clean-profile, Session V4, Agent lifecycle and Web/runtime gates pass.

Related: #34 #40 #41 #45 #46 #47 #50

[Altairpaca]

Source audit against the exact dsh-v0.1.7-rc.1 tag (46a7f68b0922371ce7144b668b90e377d8e799f4) sharpens the Session migration requirement:

• eventAt(), snapshotEvents(), and ownEvents() still exist, but upstream marks all three deprecated and prohibits new production calls;
• the upstream architecture decision explicitly directs ordinary resumed/runtime logic to reconstruct durable Session projections, maintain them incrementally from committed events, and read projection state instead of scanning historical events;
• on-demand historical content is expected to use explicit asynchronous pagination/windowed reads; complete-history reads require a justified storage path.

This matters directly to #50: the current effective-route helper scans a Session snapshot for the latest durable request/header. For the 0.1.7 migration, prefer a small route-evidence projection fed by committed request/header events (and restored on resume) over adding another synchronous history reader. Keep historical lookup only as a bounded migration/recovery path if the supported host surface requires it.