infra: host association files + fallback on invitations.dashpay.io for DIP-13 invitation applinks

[shumkov]

The example-app invitation flows (Swift + the new Kotlin port on feat/kotlin-dashpay-invitations) now emit AppsFlyer-form invitation links only — https://invitations.dashpay.io/applink?du=…&assetlocktx=…&pk=…&islock=… — matching the production wallets (owner decision; the interim dashpay://invite custom scheme is retired). For these links to open the apps, the domain needs infra work:

1. /.well-known/assetlinks.json — Android App Links verification for the example/production app package(s) + signing-cert SHA-256. The Kotlin app already ships the https intent-filter; we flip android:autoVerify="true" the moment this is served.
2. /.well-known/apple-app-site-association — iOS Universal Links for the Swift app's app id; the app then adds the associated-domains entitlement.
3. Web fallback for /applink — the path currently 404s (dead since the Firebase Dynamic Links shutdown). A tap without the app installed should land on an install/explainer page. ⚠️ The query string carries pk, a one-time bearer private key — the fallback endpoint must not log query strings (access logs, analytics, CDN logs) and should be served with strict no-referrer.
4. AppsFlyer OneLink template/credentials (optional, for the managed short-link + attribution layer) — the account creds sit with the Android team; needed only if we want OneLink-wrapped short links rather than the raw applink form.

Context: #4096 (closed) tracked the earlier universal-link migration; this supersedes it with the concrete host-side checklist. Client-side wiring on both platforms is done up to the two one-line verification flips in (1)/(2).

[HashEngineering]

Some corrections and additions from the Android production wallet (dash-wallet) side, since the issue describes its behavior slightly backwards:

What the Android wallet actually emits today. Since dashpay/dash-wallet#1410 (merged July 2025, ahead of the FDL shutdown), the shared invitation link is an AppsFlyer OneLink short link on dashpay.onelink.me (mainnet) / dashpaytest.onelink.me (testnet), not the raw https://invitations.dashpay.io/applink?… form. The raw form only exists as a deprecated accessor. The dashpay://invite?du=…&assetlocktx=…&pk=…&islock=… custom scheme is not retired on Android — it is the live deep-link payload (af_dp) embedded in the OneLink, and the manifest's only invite intent-filters today are dashpay://invite and dashwallet://invite. Deferred deep linking (tap → store → first launch) is handled by AppsFlyer attribution.

History of /applink and /link. In the Firebase Dynamic Links era the deep link was https://invitations.dashpay.io/applink?…, FDL short links lived under https://invitations.dashpay.io/link/…, and the Android manifest carried an autoVerify App Links filter for invitations.dashpay.io/applink. That filter was removed in the AppsFlyer migration, so serving assetlinks.json alone won't make /applink open the production Android wallet — we'd also re-add the https intent filter on our side (a small change; we're happy to do it once the file is live).

On the checklist:

1. assetlinks.json — for Android please include: hashengineering.darkcoin.wallet (mainnet), hashengineering.darkcoin.wallet_test (testnet), org.dash.dashpay.testnet, org.dash.dashpay.devnet, plus the example-app package. We'll supply the signing-cert SHA-256 fingerprints. Once served, we'll restore the autoVerify App Links filter in dash-wallet.
2. Web fallback for /applink — agreed this is needed; under FDL the fallback/store redirect came for free and died with the shutdown. Agree on the pk handling: no query-string logging anywhere in the chain and Referrer-Policy: no-referrer. Ideally the fallback page routes to the store via the OneLink template so deferred deep linking still works for the production wallets.
3. One more endpoint on the same host: the Android wallet's OneLink OG preview image points at https://invitations.dashpay.io/fun/invite-preview?display-name=…&avatar-url=…. Whatever is (re)deployed on invitations.dashpay.io should keep or restore that path, or link previews lose their image.
4. AppsFlyer credentials/OneLink templates — confirmed the Android team holds these (separate mainnet and testnet template IDs, brand domains above). Ping me directly and we'll get them to whoever does the infra work.

[HashEngineering]

Source for the invite preview images:
https://github.com/dash-mobile-team/dashpay-invite-preview