ops: provision a production Privy app for the Filecoin Pay console

## Summary

Provision and configure a production Privy application for the Filecoin Pay console's native email/Google login, embedded-wallet creation, and external-wallet connection flow implemented by #381.

The production App ID must be distinct from the development/test App ID `cmtkfb83p04du0bk0kofldq4e`. This issue owns Privy dashboard administration, production identifiers, allowed origins, authentication settings, security decisions, pricing approval, deployment configuration, launch validation, and operational handoff.

## Scope decision

This is a native Privy React authentication application. It is not a Privy Global Wallet provider/requester setup and does not use Privy's cross-app-connect integration.

Do not request Global Wallet provider approval, configure ecosystem sharing, wait for `cross-app/details`, or supply a provider App ID to RainbowKit. #381 replaces RainbowKit's console connection UI with Privy and keeps wagmi for blockchain interactions.

## Why production setup is separate

The development implementation can be built and reviewed with the existing development/test application. Production setup requires:

- an owner with Privy dashboard administration access;
- an owner authorized to approve a paid plan or recurring charges;
- the final production and controlled-preview origins;
- production deployment access; and
- an operational owner for post-launch access and billing.

Dashboard provisioning and pricing confirmation may proceed in parallel with #381. Final launch validation depends on #381 being merged and deployed.

## Known development resources

These resources are for development and test only and must not be reused in production:

- App ID: `cmtkfb83p04du0bk0kofldq4e`
- Web app client ID: `client-WY6d6QKpTJMyLAHudjThbGxFZiCsX4oQwkvMVSLRUKmLf`
- JWKS: https://auth.privy.io/api/v1/apps/cmtkfb83p04du0bk0kofldq4e/jwks.json

The App ID and app client ID are public identifiers. A Privy app secret is private and must never be placed in `NEXT_PUBLIC_*` variables, client code, repository files, logs, screenshots, or issue comments.

The frontend integration in #381 does not require an app secret or JWKS verification. If a later backend authenticates Privy access tokens, scope and review that server-side work separately.

## Ownership and approval requirements

- Assign a named Privy dashboard owner responsible for creating and configuring the production app.
- Assign a named backup administrator so access is not held by one person.
- Assign a billing owner authorized to accept subscription terms and recurring spend.
- Record the organization/team that owns the Privy account and the recovery/escalation path.
- Grant the least Privy dashboard access needed to maintain the application.
- Do not publish private credentials or billing details in this issue; store them in the approved organizational secret/account-management system.

## Production configuration requirements

### Application and client

- Create a new production Privy app for the Filecoin Pay console. Do not upgrade or reuse `Filecoin-Test-1` as the production application.
- Move the new app to Privy's production mode only after pricing and billing approval is complete.
- Create or select a production web app client and record its public client ID.
- Configure the application/client for the same native Privy flow accepted in #381:
- email login enabled;
- Google login enabled and tested;
- external wallets enabled; and
- Ethereum embedded wallets created for users without wallets.
- Configure an approved application name, logo, support contact, and user-facing appearance for the login and wallet prompts.
- Confirm that the production settings do not enable unused authentication methods merely because they are available.

### Allowed origins

- Allow only the exact production Filecoin Pay console origins, including protocol and any intentional `www` variant.
- Configure origins on the production app client when the client ID is passed to `PrivyProvider`; client settings override app-level settings.
- Do not add localhost to the production app.
- Do not allow a generic `*.vercel.app` or equivalent hosting-provider wildcard.
- Use the development app for local development and ordinary PR previews.
- If production credentials must be tested before launch, use an organization-controlled stable preview domain and remove it afterward unless it is part of the approved long-term setup.

### Authentication and wallet security

- Confirm the intended authentication session, access-token, refresh-token, and ID-token durations rather than accepting defaults without review.
- Review Privy's HttpOnly-cookie option and document whether it is enabled. If enabled, configure the required application domain and verify the existing Next.js deployment/session behavior.
- Keep embedded-wallet confirmation modals enabled by default unless #381 records an explicitly approved alternative consent design with complete signing-path coverage.
- Confirm that email and Google identities restore the same user and embedded wallet across logout and later login.
- Confirm that external-wallet-only connection remains available without creating an unnecessary embedded wallet.
- Do not enable server-side wallet actions, delegated actions, app-secret access, webhooks, transaction MFA, or additional wallet policies unless separately required and reviewed.

## Deployment requirements

Configure the production deployment with:

- `NEXT_PUBLIC_PRIVY_APP_ID=`
- `NEXT_PUBLIC_PRIVY_CLIENT_ID=`

Requirements:

- Store values in the approved deployment configuration, not committed source files.
- Scope them to the production environment. Development and ordinary preview builds must continue using the development/test application.
- Do not implement or configure a fallback from missing production values to the development App ID.
- Verify the values present in the built production client are the intended public production identifiers.
- Coordinate the configuration and deployment so the console is never released with required Privy variables missing.
- Document rollback as redeploying the last known-good build/configuration. Because Privy replaces RainbowKit's console connection UI, simply removing the variables is not a functional fallback.

## Pricing and billing approval

The supplied Privy dashboard snapshot from 2026-09-02 showed:

- Free: `$0/month`, up to 500 MAUs and 50,000 signatures
- Core: `$299/month`, up to 2,500 MAUs and 50,000 signatures, plus WhatsApp login
- Scale: `$499/month`, up to 10,000 MAUs and 50,000 signatures, plus custom auth and custom OAuth
- Enterprise: custom pricing, dedicated support, custom integrations, and webhooks


Treat the screenshot as a point-in-time planning artifact, not a contractual quote. Before moving the app to production:

- verify current pricing, included features, development/production limits, overage behavior, and cancellation terms with Privy;
- estimate expected monthly active users and signature volume for the console;
- confirm that email, Google, embedded wallets, external wallets, and required confirmation UI are included in the selected tier;
- select the least expensive tier that covers the confirmed launch requirements; and
- obtain explicit approval from the billing owner before selecting a paid plan or accepting recurring charges.

Record the selected tier, approval owner, approval date, expected usage band, and next review trigger without publishing private payment information.

## Launch validation

After #381 is available in the production build, validate from an approved production origin and record:

- deployment URL, date, browser, build/commit, production App ID, and production client ID;
- successful email login and embedded-wallet creation;
- logout and later login restoring the same embedded wallet address;
- successful Google login and the expected identity/wallet reuse behavior;
- successful external-wallet-only connection;
- cancel, retry, disconnect, reconnect, and page-reload behavior;
- Filecoin mainnet and Calibration network switching;
- one no-cost message signature;
- one representative Calibration transaction, including the PR #355 session-key pairing/authorization flow where practical;
- confirmation behavior for the embedded-wallet signature and transaction;
- a guided funding/Squid source-chain switching regression check; and
- confirmation that no development App ID, private app secret, or unintended origin is present in the production deployment.

Do not spend mainnet funds during launch validation without separate authorization.

## Acceptance criteria

- [ ] A named primary administrator, backup administrator, billing owner, and operational escalation path are recorded.
- [ ] A distinct production Privy app and production web app client exist; neither development identifier is used.
- [ ] The production app is configured for native email and Google login, external wallets, and Ethereum embedded wallets for users without wallets.
- [ ] Approved application branding and support information appear in user-facing Privy prompts.
- [ ] Only approved production or controlled-preview origins are configured; localhost and generic hosting-provider wildcards are absent.
- [ ] Session durations, HttpOnly-cookie behavior, and wallet confirmation policy have been reviewed and documented.
- [ ] Current Privy pricing and feature availability are verified, expected usage fits the selected tier, and any paid plan has explicit billing-owner approval.
- [ ] The production App ID and client ID are configured in the production deployment without exposing an app secret.
- [ ] The production build contains no development App ID fallback.
- [ ] #381 is merged/deployed and production smoke testing passes for email, Google, embedded-wallet persistence, external-wallet connection, network switching, signing, cancellation, and retry.
- [ ] A Calibration console transaction succeeds; no mainnet funds are spent without separate authorization.
- [ ] Rollback and post-launch ownership are documented.
- [ ] A final issue comment records the non-secret identifiers, configured origins, selected plan, owners, deployment/build, test date, and pass/fail evidence.

## Dependencies and ordering

- Implementation: #381
- Implementation stack prerequisite: [PR #355](https://github.com/FilOzone/filecoin-pay-explorer/pull/355)

Provisioning, origin planning, and pricing approval may proceed in parallel with implementation. Production deployment and final smoke testing depend on #381 being merged and available in the release.

## Out of scope

- Implementing or redesigning the Privy React/wagmi integration
- Privy Global Wallet provider/requester, ecosystem sharing, or cross-app-connect configuration
- RainbowKit connector configuration
- Reusing the development/test app in production
- Privy Onramp, card/ACH funding, or changes to the existing USDC-to-USDFC flow
- Custom OAuth, WhatsApp, SMS, passkeys, Apple login, webhooks, or Enterprise-only features
- Backend access-token verification or app-secret use
- Mainnet transactions that incur cost during validation

## References

- [Implementation issue #381](https://github.com/FilOzone/filecoin-pay-explorer/issues/381)
- [Privy React setup](https://docs.privy.io/basics/react/setup)
- [Privy app clients](https://docs.privy.io/basics/get-started/dashboard/app-clients)
- [Automatic embedded-wallet creation](https://docs.privy.io/basics/react/advanced/automatic-wallet-creation)
- [Privy and wagmi integration](https://docs.privy.io/wallets/connectors/ethereum/integrations/wagmi)
- [Connecting external wallets](https://docs.privy.io/wallets/connectors/usage/connecting-external-wallets)
- [Wallet confirmation modals](https://docs.privy.io/recipes/react/manage-wallet-UIs)
- [Allowed origins](https://docs.privy.io/recipes/dashboard/allowed-domains)

Start by reviewing implementation issue #381 and the Privy React setup, then coordinate dashboard ownership, production origins, pricing approval, and deployment access. Configure the distinct production app and client, then validate the production deployment against the listed login, wallet, network, signing, and Calibration transaction checks after #381 is merged. Done means the acceptance criteria, rollback plan, owners, and non-secret launch evidence are recorded.

Written by the indexing model from the issue text.