Prevent the "already owned" deploy collision: npm run name:new

[sacha-l]

Problem

The template ships a hardcoded contract package name (@rps/leaderboard). On the shared registry that name is already owned by the original deployer's signer, so the first thing anyone modding this app hits on pg deploy (or npm run deploy) is:

✖ CDM package "@rps/leaderboard" is already owned by 0x35cdb…, but the selected
  signer maps to 0xcf8a…. Update the contract Cargo.toml [package.metadata.cdm]
  package = "..." value to a package name you own, or deploy with the owner account.

The error leads with "rename it," but every predictable replacement (@rps-<x>, @<handle>-rps, @<repo-id>/…) tends to already be owned too — so modders (and coding agents) collide repeatedly, renaming under the same signer each time. The root issue is shipping a guessable name with no way to verify ownership before signing.

Fix

Stop shipping a guessable name; make claiming a fresh one one command.

• scripts/new-contract-name.mjs (npm run name:new) — generates a high-entropy, effectively-unowned name (@rps-<8hex>/leaderboard) and rewrites it in cdm.json + contracts/leaderboard/Cargo.toml. Pass your own to override: npm run name:new @me/scoreboard.
• src/utils.ts — derive the package name from cdm.json instead of hardcoding it in three string literals, so there's a single source of truth. A miss when hand-syncing the name previously surfaced as a silent runtime resolve failure, not a build error.
• README — document npm run name:new as the first step of modding.

Why this shape

• Contract-agnostic — no change to contract logic, ABI, or the deploy pipeline; works regardless of what a modder does to the contract.
• No new dependencies — the script uses only Node built-ins (fs, crypto).
• No getOwner required — a random name sidesteps the (currently unverifiable) ownership check entirely.

Verification

• npm run name:new rewrites both files correctly and is idempotent/guarded (rejects invalid or unchanged names).
• tsc -b passes with the utils.ts change.
• Frontend resolves the contract via the derived name unchanged.

Follow-up (not in this PR)

An offline dev mode (?mock backed by an in-memory leaderboard) lets a modder verify register/play/leaderboard with no chain, phone, or deploy — closing the "you can only discover problems by doing an irreversible deploy" loop. Happy to open that as a separate PR if of interest.

[cla-bot-2021]

User @claude, please sign the CLA here.

[sacha-l]

Part of the modding-DX umbrella: #13 (this PR is item 2 — auto-claim a unique name).

[illegalcall]

1. The header comment references DEVEX-REPORT.md and DEPLOY-LOG.md, which only exist on your fork. Reference issue Modding DX: make fork → mod → deploy smooth (surface identity, ownership & offline verification before the irreversible deploy) #13 instead so the citation resolves for readers of this repo.

2. The printed "Next:" steps inline a specific pg build / pg deploy ... invocation. That's a second deploy flow alongside the one DEPLOYMENT.md documents (npm run deploy for the contract, then playground deploy ... for the frontend/playground), and the inlined flags will drift as endpoints change. Point at DEPLOYMENT.md instead of hardcoding a command.

3. The ?mock URL from the output. It only works if Add offline dev mode (?mock): run & verify a mod with no chain, phone, or deploy #12 merges