ci: qualify DSH 0.1.5 candidate source graph in isolation

[Altairpaca]

Why

DSHelm now has source-level bridges for the DSH 0.1.5 Session, subagent and Web panel seams, but the committed package graph must remain the verified 0.1.0-rc.7 baseline until candidate evidence passes. We need a machine lane that tests the current candidate without rewriting that baseline first.

Change

• add a dedicated dsh-candidate-source workflow;
• read the candidate version from compatibility-candidates.json rather than hard-coding it into the workflow;
• transiently rewrite only the Actions checkout to a coherent candidate graph;
• install the exact published @deepseek-ai/dsh@0.1.5-rc.1 host in the disposable checkout so its prerelease peer cohort is resolved as a real host installation rather than through stable-looking peer ranges;
• align DSHelm's direct DSH dependencies in both @dshelm/dsh and CLI;
• replace the legacy Web client dependencies/injects with the current minimal service graph: @deepseek-ai/dsh-api-session-controller for sessions and @deepseek-ai/dsh-client-ui-renderer for slots;
• transiently align the CLI's direct pi-ai discovery dependency to 0.85.1 for the 0.1.5 experiment;
• preserve the repository minimum-release-age policy while adding only exact 0.1.5-rc.1 counterparts for already-reviewed DSH package names in the disposable candidate checkout;
• run candidate install (without native lifecycle scripts), graph assertions, workspace typecheck/build, compatibility-sensitive tests and client bundle verification.

Evidence found during qualification

The first lane run failed before source compilation because current DSH prerelease peers such as @deepseek-ai/dsh-sandbox@>=0.1.5 <0.2.0-0 do not themselves select the 0.1.5-rc.1 package published on the next dist-tag. Adding the exact DSH host cohort makes package resolution succeed.

The second run resolved the full candidate host graph, then stopped at pnpm's minimum-release-age verification for same-day 0.1.5-rc.1 packages. The lane now seeds exact candidate-version exclusions only for DSH names already present in the verified baseline; it does not disable the policy or wildcard-approve future versions.

These are package/policy qualification findings, not evidence of source/runtime incompatibility.

Evidence boundary

This lane proves package availability and source/type/build compatibility only. It does not mutate committed manifests or lockfiles, execute native install scripts, prove Session V3 persistence, prove Web materialization inside a live 0.1.5 Web profile, or promote compatibility.json.tested.

Refs #34 #41 #47.