Host-papp declares `polkadot-api: ">=2"` but imports `polkadot-api/signer`, which papi 3 removed

@novasamatech/host-papp@0.9.4 (latest) declares its polkadot-api dependency as ">=2" while importing the polkadot-api/signer subpath. polkadot-api 3.0.0 (published 2026-08-18) removed that subpath. The declared range therefore permits a version the code cannot run against, so npm resolves papi 3 happily and the package explodes at import time — before any of its own code executes.

Reproduction

mkdir /tmp/hp && cd /tmp/hp && echo '{"type":"module"}' > package.json
npm install @novasamatech/host-papp@0.9.4 polkadot-api@3.0.0
node --input-type=module -e 'await import("@novasamatech/host-papp")'

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './signer' is not defined by
"exports" in /tmp/hp/node_modules/polkadot-api/package.json
  imported from /tmp/hp/node_modules/@novasamatech/host-papp/dist/sso/allowance/impl.js

References to the removed subpath in 0.9.4:

• dist/sso/allowance/impl.js
• dist/sso/allowance/impl.d.ts
• dist/sso/auth/attestationService.js

What papi 3 changed

polkadot-api/signer → polkadot-api/tx-creator, and the function was renamed too:

papi 2:  import { getPolkadotSigner } from "polkadot-api/signer"
         getPolkadotSigner(publicKey, "Sr25519", sign)   -> PolkadotSigner
papi 3:  import { getTxCreator } from "polkadot-api/tx-creator"
         getTxCreator(publicKey, "Sr25519", sign)        -> CommonSignerTxCreator

Identical argument list — publicKey, "Ecdsa" | "Ed25519" | "Sr25519", sign — so the call sites are a mechanical swap. Verified against papi.how/signers/raw and @polkadot-api/raw-tx-creator/dist/index.d.ts in an installed papi 3.0.0.

Note the 3.0.0 release note says only "Renamed polkadot-api/signer to polkadot-api/tx-creator", which reads like a pure subpath change. It isn't: getPolkadotSigner exists nowhere in papi 3 and is not on the root export, so changing only the import path yields undefined rather than a working function.

Impact

Consumers reach this through @parity/product-sdk-terminal → @novasamatech/host-papp. Concretely, in bulletin-deploy:

• A plain npm install bulletin-deploy is unaffected — our polkadot-api: ^2.1.3 resolves to 2.2.2, which still exports ./signer.
• A consumer that also depends on polkadot-api@^3 gets papi 3 hoisted to the top level, host-papp's subpath import resolves against it, and import("bulletin-deploy") fails outright — no code of ours runs, so there is nothing we can guard.

Every downstream of @parity/product-sdk-terminal has the same exposure, and it widens as papi 3 adoption spreads.

Suggested fix, in preference order

1. Migrate to getTxCreator and declare polkadot-api: ">=3" (or ^3). Cleanest; the call sites are a rename.
2. If papi 2 must stay supported, narrow the range now — polkadot-api: ">=2 <3" — so npm stops resolving a version the code cannot use. This is the one-line stop-gap and is worth shipping even if (1) is planned, because today the range actively misleads the resolver.

Supporting both majors from one build means a conditional import of a subpath that doesn't exist in one of them, which is awkward enough that (1) or (2) is likely preferable to attempting it.

Either way the fix wants a matching release of @parity/product-sdk-terminal so downstreams pick it up.

Start by running the provided npm reproduction with polkadot-api 3.0.0, then inspect dist/sso/allowance/impl.js, dist/sso/allowance/impl.d.ts, and dist/sso/auth/attestationService.js for the removed signer imports. Check the package dependency declaration and verify that host-papp imports successfully with the supported papi version; confirm the downstream package release receives the compatible dependency.