chore: refresh Product DevNet platform pins

[knzeng-e]

Outcome

Dotify now targets the refreshed September 2026 Product DevNet baseline before
we continue the next implementation contract. The Product app build, Product
SDK pins, Bulletin descriptor, Bulletin deploy defaults, Product CDM registry,
checked-in Product catalog fixture/bootstrap, and public Product architecture
copy are aligned with the post-reset DevNet state.

Issue and context

Refs #85.

The Product DevNet update reset key platform assumptions: new app records must
use the current DotNS/Bulletin tooling, the CDM devnet registry moved, and chain
descriptors had to be refreshed. Dotify had already been redeployed once from
dev, but the repository still carried the pre-reset Product SDK/tooling
baseline and old CDM registry target. Keeping those values would make future
Product host smoke tests ambiguous: a failure could come from Dotify, stale
DotNS tooling, stale Bulletin metadata, or writes to the retired CDM registry.

This PR is intentionally not W06. It is a platform alignment PR that makes W06
and the next Product host checks meaningful.

Local scope and evidence:

• docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md
• docs/backlog/implementation/evidence/product-devnet-platform-refresh-2026-09.md

External context:

• https://forum.polkadot.network/t/polkadot-product-devnet-update/18602
• https://docs.polkadotcommunity.foundation/reference/addresses/

Architecture and key concepts

The change keeps Dotify dual-mode:

• standalone web remains the production spine;
• Product host mode remains a progressive enhancement;
• Product CDM writes remain opt-in through VITE_DOTIFY_RUNTIME_ADAPTER;
• backend key custody and server-side upload boundaries do not move.

The platform alignment has five concrete boundaries:

1. Product host packages are pinned exactly in web/package.json so we know
   which host API and Product SDK graph the bundle was built against.
2. Product deployment uses polkadot-app-deploy@0.16.2 so the app publishes
   through the post-reset DotNS/Bulletin path.
3. PAPI Bulletin descriptors are generated from the refreshed Bulletin endpoint
   so Statement Store types match the new runtime.
4. Bulletin deployment and frontend archival fallbacks now default to
   wss://bulletin-paseo.tservices.es:8443, avoiding a mixed new-descriptor /
   old-chain runtime.
5. Product CDM devnet writes target
   0x05662b3dbd5dd9f2ff92d67630477e84b0b37c1f; the old registry remains
   documented only as a stale-readable address that must not receive new
   registrations.

Root polkadot-api is not upgraded in this PR. Product SDK 0.27.0 carries
its own PAPI 2.2.x tree, while the @polkadot-apps signer stack still uses
PAPI 1.23.x. Moving Dotify's root PAPI to 3 stays a separate compatibility
PR.

How it works

For a Product DevNet deployment, npm run deploy:product-devnet now:

1. checks that the DotNS owner MNEMONIC exists;
2. builds the Product bundle and refreshes the Product catalog bootstrap;
3. publishes dist-product through
   @polkadot-community-foundation/polkadot-app-deploy@0.16.2;
4. advertises executable version [0, 1, 15].

For the older single-file Bulletin deployment, npm run deploy:bulletin now
defaults to the refreshed Product DevNet Bulletin endpoint and prints the
post-reset Bulletin gateway URL unless BULLETIN_GATEWAY_URL overrides it.

For CDM, npm run cdm:publish:testnet remains read-only unless --confirm is
passed. The dry-run now checks the new registry and reports the exact
publishLatest plan before any irreversible name ownership/write happens.

Design decisions and tradeoffs

• Pin the Product SDK set exactly instead of using ranges. Product host APIs
  are still moving, and exact pins make host smoke evidence reproducible.
• Keep root PAPI unchanged. This avoids mixing the Product platform refresh
  with a cross-ecosystem PAPI 3 migration.
• Keep CDM publish as a separate operator step. This PR verifies the new
  registry and updates defaults, but it does not submit irreversible registry
  writes during code review.
• Keep generated PAPI descriptor files in the diff. They are the runtime type
  evidence for the refreshed Bulletin chain and should not be regenerated
  implicitly in CI without review.
• Keep Pinata and generic public gateways first for current track-asset reads;
  Product IPFS gateways are appended for artwork/metadata fallback while DAV2
  audio remains restricted to Pinata gateways.

Security, failure, and operations

• No production secrets are introduced.
• No frontend fallback signer or hidden dev account is introduced.
• Product CDM publication remains explicit, read-only by default, and warns
  that registry name ownership is effectively permanent.
• Product app redeploy is still a post-merge operator action because it needs
  the DotNS owner mnemonic.
• The old CDM registry and retired Bulletin endpoint are not active defaults.
• docs/index.html now states the reset and the remaining live
  republication/smoke boundary for the public page.
• npm audit fix --force was not run. The remaining audit issues require
  Product/PAPI, React/Vite, or Hardhat compatibility decisions, not automatic
  lockfile churn.

Review guide

Suggested order

1. web/package.json and web/package-lock.json - confirm the Product SDK and
   deploy tooling pins are exact and scoped to Product DevNet alignment.
2. web/.papi/polkadot-api.json and web/.papi/descriptors/** - confirm only
   Bulletin was re-pinned and generated against the refreshed endpoint.
3. web/scripts/deploy-bulletin.cjs, web/src/shared/config/network.ts, and
   web/src/services/pinata.ts - confirm the old Bulletin/IPFS endpoints are
   not active defaults.
4. contracts/evm/tasks/cdmPublish.ts and contracts/evm/cdm.json - confirm
   the CDM devnet registry points at the new Product registry and the task is
   still dry-run by default.
5. web/polkadot-app-deploy.config.ts,
   web/fixtures/product-devnet-catalog.json, and
   web/src/services/productDevnetCatalogBootstrap.ts - confirm the executable
   version bump and aligned 8-item catalog fixture/bootstrap.
6. Docs and evidence - confirm the operational guidance distinguishes code
   readiness from live deployment/CDM publication.

Verify carefully

• Does any Product failure path silently fall back to a hidden signer or
  bypass wallet access?
• Are old CDM registry references warnings only, not active defaults?
• Does the PR keep Product mode progressive rather than making it required
  for standalone listening?
• Are post-merge live actions explicit enough for an operator to execute
  without guessing?

Validation

Evidence	What it proves
node --check web/scripts/deploy-bulletin.cjs	Bulletin deploy script still parses after fallback refresh.
`rg -n "paseo-bulletin-rpc	paseo-ipfs\.polkadot\.io" README.md docs web -g '!web/node_modules/**'`
npm --prefix web run fmt:check	Frontend tracked source formatting still passes.
npm --prefix web run lint	Frontend lint passes with 3 existing React hook dependency warnings.
npm --prefix web run test:unit	52 files and 400 unit tests pass against the new SDK graph and gateway defaults.
npm --prefix web run build	Standard web bundle still builds.
npm --prefix web run build:product-devnet	Product bundle builds; in the local sandbox the live catalog fetch was unavailable and the existing fixture-generated bootstrap was kept.
npm --prefix web run generate:product-catalog-bootstrap:strict -- --input fixtures/product-devnet-catalog.json	Deterministic fixture generation writes the same 8-item bootstrap expected by CI.
CATALOG_API_URL=http://127.0.0.1:9 npm --prefix web run build:product-devnet	CI-style offline Product build keeps the fixture-generated bootstrap and leaves no drift.
npm --prefix web run smoke:devnet	Asset Hub chain, deployed Dotify contracts, Bulletin RPC, and IPFS gateway respond.
npm --prefix web run generate:cdm	Generated CDM manifest remains stable after contract compile.
npm --prefix web run generate:cdm-metadata	Deterministic CDM metadata CIDs remain stable.
npm --prefix contracts/evm run fmt:check	Contract TS/Solidity formatting passes.
npm --prefix contracts/evm run compile	Hardhat compile passes.
npm --prefix contracts/evm run cdm:publish:testnet	Dry-run reaches the new registry and reports 2 update-version entries, without sending transactions.
node scripts/backlog-sync.mjs --check --offline	Backlog manifest check passes with known existing offline warnings.
git diff --check	No whitespace errors remain.
npm --prefix web audit --audit-level=moderate	Expected residual risk remains: 32 findings; no forced fix applied.
npm --prefix web audit --omit=dev --audit-level=moderate	Expected residual runtime risk remains: 28 findings; no forced fix applied.
npm --prefix contracts/evm audit --audit-level=moderate	Expected Hardhat 2 dev-tooling risk remains: 25 findings; no forced fix applied.
npm --prefix contracts/evm audit --omit=dev --audit-level=moderate	Runtime contracts package audit is clean: 0 vulnerabilities.
Remote PR checks on 902b5b9	W01 workflow, offline manifest, and Netlify checks pass. claude-review still fails before review because enterprise policy blocks the external Claude marketplace.

Known limitations and follow-ups

• This branch was not deployed to Product DevNet. After merge, publish the app
  bundle again so dotify-test01.dot exposes executable [0, 1, 15].
• CDM writes were not submitted. The dry-run says two Dotify names would publish
  update-version entries to the new registry when the operator runs with
  --confirm.
• Real Product host smoke still has to be run after deployment: open app,
  connect Product account, create/join room, verify guest audible playback, and
  verify Product CDM payment/read-back if that adapter is enabled.
• Root PAPI 3, React 19, Vite 8, and Hardhat 3 remain separate migrations.

Metadata checklist

• Backlog issue linked with correct reference semantics: Refs [Product SDK][P1] Prove Product host compatibility before integration #85
• Local backlog/evidence document linked
• Added to Project 5 (Dotify sprints)
• Project Priority, Track, Phase, Type, and Backlog doc mirror the issue
• Workflow status matches review state: ready for review
• Assignee set
• Applicable labels set
• Applicable milestone set, or confirmed none exists
• Reviewers requested when ownership is known
• Draft/ready state is intentional

[netlify]

✅ Deploy Preview for muzinga ready!

Name	Link
🔨 Latest commit	902b5b9
🔍 Latest deploy log	https://app.netlify.com/projects/muzinga/deploys/6aa4ebd5d849ba0008456b0c
😎 Deploy Preview	https://deploy-preview-147--muzinga.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-12T05:51:37.598059Z	e0c4955	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e0c4955350

ℹ️ 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".