chore: align Product SDK package set

[knzeng-e]

Outcome

Align Dotify's Product DevNet adapter with the latest published Product SDK package set while keeping the standalone web path, Product build, Product CDM opt-in adapter, and dormant Statement Store beacons compiling.

This PR intentionally does not move Dotify's root polkadot-api dependency to 3.0.0. I tested that path during the compatibility pass: the current official Product SDK packages bring their own PAPI 2.2.x tree, while @polkadot-apps/chain-client, keys, and signer still use PAPI 1.23.x. A root PAPI 3 trial removed the public PolkadotSigner export and broke ChainDefinition / TypedApi compatibility at the Bulletin and wallet seams.

Issue and context

Refs #85.

Local scope and context:

• docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md
• docs/explanation/product-devnet-architecture.md
• docs/operations/dependency-security-status.md
• docs/operations/deployment-configuration.md

#85 is broader than this PR. The remaining issue scope is host transaction signing, resource allocation, and real Product Desktop/Web smoke evidence. This PR handles the dependency compatibility slice and records the PAPI 3 blocker so future work does not repeat the same migration attempt blindly.

Architecture and key concepts

Dotify now uses this Product/PAPI dependency shape:

Dotify root
  polkadot-api 1.23.3
  @polkadot-apps chain-client/keys/signer
    used for existing Bulletin + passkey/SS58 support

Product SDK 0.23.0 package set
  transitive polkadot-api 2.2.x
  used through lazy Product host/CDM/Statement Store adapters

PAPI 3.0.0
  latest on npm, but not adopted at root yet
  blocked by current upstream package type incompatibility

The Product SDK packages remain exact pins because Product host behavior is still moving. Product CDM remains opt-in behind VITE_DOTIFY_RUNTIME_ADAPTER=product-cdm; the tracked Product deployment still defaults to the existing viem runtime path.

I also checked whether this was the moment to replace the existing Bulletin client with @parity/product-sdk-chain-client. That client is host-only and has no direct WebSocket fallback, so replacing the existing @polkadot-apps/chain-client path would regress standalone Bulletin publication. Keeping both surfaces is deliberate until the Product host path can cover the same user flows.

How it works

• web/package.json moves:
  • @parity/product-sdk to 0.23.0
  • @parity/product-sdk-host to 0.16.0
  • @parity/product-sdk-statement-store to 0.6.5
  • @parity/product-sdk-descriptors to 0.10.0
• web/package-lock.json records the resulting dependency graph and minor lockfile collateral inside already-declared ranges.
• web/src/services/productDevnetCatalogBootstrap.ts was regenerated from the live catalog API during Product build validation and still contains the same 5 catalog items.
• Product/CDM generated artifacts were regenerated locally and produced no diff, which is useful evidence that the SDK contracts/codegen surface remains compatible with the current generated bindings.
• Docs now record the exact current versions, the root PAPI 3 blocker, residual audit status, and the next Product evidence needed.

Design decisions and tradeoffs

Chosen:

• Adopt the latest Product SDK set now, because those packages are directly inside [Product SDK][P1] Prove Product host compatibility before integration #85's reviewed scope.
• Keep root polkadot-api on 1.23.3, because forcing 3.0.0 creates a fragile multi-major graph that does not compile without shims.
• Keep the standalone web/Bulletin path first-class, because Dotify's north star requires first sound and artist workflows outside a Product container.
• Document the PAPI 3 blocker explicitly instead of hiding it as "deferred".

Deferred:

• Root PAPI 3 migration, until Product SDK and @polkadot-apps converge on a compatible PAPI major.
• Replacing standalone Bulletin chain access with Product SDK chain-client, because the current SDK chain-client is host-only.
• Hardhat 3 migration and broader framework upgrades, because they are unrelated breaking migrations.

Security, failure, and operations

No secrets, hosted dashboard values, CORS origins, Fly/Netlify config, or runtime env names change in this PR.

Security posture is unchanged:

• no production secrets move into the frontend;
• missing Product host capability remains explicit;
• Product CDM writes remain opt-in;
• room guests remain walletless;
• backend key delivery remains authoritative.

npm audit still reports 26 high-severity findings in the web runtime graph through Product/PAPI transitives. Product SDK latest does not remove those findings, and npm audit fix --force would cross breaking boundaries. The status is documented in docs/operations/dependency-security-status.md.

docs/index.html is intentionally unchanged because this PR does not change public positioning, visual identity, or the user-facing roadmap.

Review guide

Suggested order

1. web/package.json and web/package-lock.json
   Confirm the direct Product SDK pins and inspect the resulting PAPI multi-version graph.
2. docs/operations/dependency-security-status.md
   Check whether the audit result and PAPI 3 blocker are described honestly.
3. docs/operations/deployment-configuration.md
   Verify the operator-facing Product dependency matrix and that no env/dashboard change is implied.
4. docs/explanation/product-devnet-architecture.md
   Review the compatibility gate and confirm the architecture still preserves standalone first sound.
5. docs/backlog/* and spec.md
   Confirm the planning docs no longer point future work back to the old Product SDK snapshot.
6. web/src/services/productDevnetCatalogBootstrap.ts
   Confirm the refresh only updates live snapshot metadata and still carries 5 items.

Verify carefully

• Does any public path now require Product host APIs before catalog/playback can work?
• Is root PAPI 3 correctly treated as blocked rather than silently adopted?
• Are Product SDK packages pinned exactly enough for repeatable DevNet builds?
• Does Product CDM remain opt-in instead of changing default runtime writes?
• Are audit findings documented without implying they are fixed?
• Does the refreshed bootstrap snapshot avoid changing track identity or access data?

Validation

Evidence	What it proves
npm view @parity/product-sdk version -> 0.23.0	Latest published Product SDK was checked before the PR.
npm view @parity/product-sdk-host version -> 0.16.0	Latest host package was checked before the PR.
npm view @parity/product-sdk-statement-store version -> 0.6.5	Latest Statement Store package was checked before the PR.
npm view @parity/product-sdk-descriptors version -> 0.10.0	Latest Product descriptors package was checked before the PR.
npm view polkadot-api version -> 3.0.0	Root PAPI latest was checked; it is documented as blocked.
npm view @polkadot-community-foundation/polkadot-app-deploy version -> 0.13.1	Product deploy tool remains current.
npm ls @parity/product-sdk @parity/product-sdk-host @parity/product-sdk-statement-store @parity/product-sdk-descriptors polkadot-api	Installed graph matches the documented Product SDK 0.23.0 set and mixed PAPI major reality.
npm run generate:cdm	Product SDK contracts/codegen still generates the same CDM artifacts; no diff.
npm run generate:cdm-metadata	SDK cloud-storage CID generation remains deterministic; no diff.
npm run build	Standalone production build compiles. Vite still reports existing chunk-size/dynamic-import warnings.
npm run test:unit	41 files / 324 tests pass.
npm run lint	ESLint exits 0 with 3 existing hook dependency warnings.
npm run build:product-devnet with network access	Product build compiles and refreshes 5 bootstrap catalog items from the public API.
npm run build:product-devnet:beacons with network access	Statement Store beacon build compiles with the updated statement-store package.
npm audit --audit-level=moderate and npm audit --omit=dev --audit-level=moderate	Both still fail with 26 high Product/PAPI-chain findings; documented as residual risk.
git diff --check	No whitespace errors.

Known limitations and follow-ups

• Root polkadot-api@3.0.0 is not yet deployable for Dotify because the official Product SDK and @polkadot-apps packages are not on one compatible PAPI major line.
• Product host transaction signing and resource allocation remain the next [Product SDK][P1] Prove Product host compatibility before integration #85 implementation/evidence step.
• Product Desktop/Web/Mobile live host smoke tests still need to be captured after this PR is merged and deployed.
• The Product/PAPI audit chain remains unresolved upstream; do not use npm audit fix --force as a shortcut.

Metadata checklist

• Backlog issue linked with correct close/reference semantics (Refs #85)
• Local backlog document linked
• Added to Project 5 (Dotify sprints)
• Project Priority, Track, Phase, Type, and Backlog doc mirror the issue
• Workflow status matches draft/review state
• Assignee set
• Applicable labels set
• Applicable milestone set, or confirmed none exists
• Reviewers requested when ownership is known
• Draft/ready state is intentional

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0dec22d7fb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Bump the Product executable version with the SDK bundle

When this Product build is published for users who previously opened it in the mobile host, the upgraded SDK code can retain the unchanged [0, 1, 11] executable metadata from web/polkadot-app-deploy.config.ts:13, allowing the host to keep its cached bundle instead of loading this release. The deployment runbook explicitly requires an appVersion bump for host SDK integration changes (docs/operations/deployment-configuration.md:160-164), so increment the manifest version alongside these pins.

Useful? React with 👍 / 👎.

[knzeng-e]

Addressed in 73d3fc1: bumped the Product executable manifest to [0, 1, 12] and aligned the deployment/runbook docs so the current executable version is cache-busted while the 0.1.11 Product Mobile WebRTC fallback remains documented as 0.1.11 and later.