[Product SDK][P1] Prove Product host compatibility before integration

[knzeng-e]

Outcome

Maintain Dotify as a first-class Polkadot Product and make every Host capability claim evidence-based while preserving the standalone web path.

Delivered slices

• Product/standalone adapter boundary, Host detection, explicit degradation, and pinned Product SDK packages.
• Product manifest, DotNS/Bulletin publication, Product chain reads, app-scoped account derivation, and Product sr25519 key/session requests.
• Experimental Product CDM runtime writes, native PAS value conversion, effective payer address display, purchase recovery, and proof links.
• Product app [0, 1, 26] published as a validation profile.
• W16 concluded that current Product CASH callbacks cannot authorize Asset Hub runtime access; CASH remains non-executable.

Remaining epic gates

• Candidate-bound Product Desktop payment/access and room exports for W13.
• Current compatibility evidence for Desktop, Web, mobile continuation, permissions, and outbound requests.
• Explicit decisions for capabilities the Host does not expose; no hidden browser-wallet or demo-signer fallback.
• Promotion of a Product write profile only after authoritative settlement/read-back evidence.

Boundary

This epic coordinates Product compatibility. Delivered slices stay closed in their own issues, and W13 owns pilot acceptance. Do not rebuild the adapter layer or treat a Completed CASH callback as an access proof.

Local scope: docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md.

[knzeng-e]

Backlog sync 2026-07-14: this is now a Product SDK feasibility epic, not an implementation ticket. Scope is split into SDK version/Host compatibility, Product account signing and resource allocation, PolkaVM/CDM contract portability, Playground/Bulletin/DotNS deployment, and Statement Store presence constraints. Standalone web remains first-class. Current source of truth: docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md.