Add Unstoppable Wallet as an OpenCryptoPay payment-link wallet

[joshuakrueger-dfx]

Register Unstoppable Wallet (Horizontal Systems) in the wallet_app catalog so it is offered as a payment app on the payment-link pages (app.dfx.swiss/pl). The wallet list on those pages is served from this table via GET /v1/paymentLink/walletApp.

Supported transfer methods

Unstoppable ships native OpenCryptoPay support on iOS and Android. The eleven methods below were read off the app sources on 2026-07-28, not taken from documentation:

• iOS — OpenCryptoPayBroadcasterFactory.unstoppable registers EvmHex, TronHash, BitcoinHex, SolanaHash, ZanoHash and MoneroHash broadcasters; the union of their supportedChains maps yields the method names.
• Android — OcpTransferAmount.supportedBlockchainTypes() in OpenCryptoPayRepository.kt lists the same eleven.

Ethereum;BinanceSmartChain;Polygon;Arbitrum;Optimism;Base;Bitcoin;Solana;Tron;Zano;Monero

The six EVM chains are listed explicitly rather than via the EvmBlockchains placeholder: EvmBlockchains additionally contains Gnosis, Haqq, Citrea and CitreaTestnet, which Unstoppable does not OCP-broadcast. See WalletApp.supportedBlockchainList.

Columns left unset

recommended, semiCompatible and assets stay NULL — a normal, fully compatible wallet with no asset restriction.

hasActionDeepLink also stays NULL, and that is deliberate. Per SetRealUnitHasActionDeepLink, the flag means a non-Lightning wallet takes the payment through <deepLink>lightning:<LNURL>. For Unstoppable that path does not exist: OpenCryptoPayUrl.detect accepts only URLs with scheme == "https" carrying a lightning query parameter, so unstoppable.money:lightning:… falls through DeepLinkManager.handle into the address parser and ends in the "cannot recognize" banner. Behaviour matches Cake Wallet (flag NULL), not RealUnit.

deepLink is the bare custom scheme unstoppable.money:, registered on both platforms (iOS Info.plist CFBundleURLTypes, AndroidManifest.xml), so the frontend's open-app action works.

down() ownership

up() skips an existing Unstoppable Wallet row via its SELECT guard. A name-only DELETE in down() would therefore remove a row this migration never created — a hand-created or later edited row would be destroyed by an up/down cycle. down() additionally matches the characteristic values up() writes (deepLink + blockchains), the same exact-value idiom used by SetRealUnitHasActionDeepLink and PopulateNativeCoinDecimals.

Test

add-unstoppable-wallet-app.migration.spec.ts mirrors AddSavingZchfAsset: a mocked-queryRunner suite for the SQL content and a real-Postgres suite gated on MIGRATION_TEST_PG (set in api-pr.yaml).

The ownership test creates a foreign Unstoppable Wallet row with a different deepLink before up() and asserts that an up()→down() cycle leaves it intact. Verified to fail without the guard: reverting down() to the unconditional form turns the suite red — 1 of 1 suite, 2 of 7 tests, the Postgres one with Expected length: 1, Received length: 0. With the guard: 7 of 7 pass.

Precedent

wallet_app is maintained by migration, not by hand: AQUA (#3909), urble (#3674) and RealUnit (#4339) all landed that way and none was ever withdrawn (git log --diff-filter=D over migration/*allet* is empty). The id-less INSERT is equally established — RealUnit went in through the same shape and was assigned id 27, the highest in production, so the sequence is not lagging.

Not verified

The migration has not been run against the production database; idempotency and the up/down cycle are covered by the Postgres spec against a fixture table. No real payment was made from the Unstoppable app — this PR makes the wallet selectable, it does not exercise a payment.