Model DSH web-client contracts separately from headless host resolution #75

Why this matters

The first ten-plugin live run installed and loaded three web plugins successfully, then reported missing or mismatched client-side peers from the headless Node resolution anchor. Their published manifests declare dsh.client.platform as web, so these signals are useful review evidence but are not yet proof that the plugin fails in its intended client plane.

Live evidence: https://github.com/MicroMilo/upstream-radar/actions/runs/32615754861
Related managed review incidents: #70, #71, #72.

Required model change

• Preserve dsh.client.platform and dsh.client.inject from the exact tarball in the compatibility IR.
• Add the selected DSH profile or execution plane to each maintained compatibility cell.
• Classify literal imports from the host entry separately from imports in the client export.
• Verify host peers against the host runtime and web-client peers against the web injection/module contract.
• Keep client-plane coverage gaps non-actionable until the intended plane has been tested.
• Reconcile [DSH compatibility] dsh-better-sidebar@0.15.2 on DSH 0.1.1-rc.2 / Node 22: peer-contract-incompatible #70, [DSH compatibility] @zseven-w/dsh-openpencil@0.1.0-rc.1 on DSH 0.1.1-rc.2 / Node 24: peer-contract-incompatible #71, and [DSH compatibility] @sanqi-normal/dsh-webui-market-plugin@0.5.5 on DSH 0.1.1-rc.2 / Node 22: peer-contract-incompatible #72 after the new evidence model runs; only then consider upstream author issues.

Acceptance

A web-only client peer that is absent from the headless Node anchor must not create an author-actionable incompatibility by itself. A host import failure, an incompatible resolved client module, or a failed intended-profile boot should remain actionable with exact evidence.