Add invite-code access and a safe Testnet-to-Mainnet switch

## Goal

Let invited users access Miden Mainnet from the existing Bread wallet, while keeping Testnet available to users who have not received access.

This is separate from #875, which makes the current Testnet experience clear. Installing Bread or joining an early-access list must not imply that Mainnet access has already been granted.

## Proposed user flow

1. A user on Testnet chooses to switch to Mainnet.
2. If access has not been granted, Bread explains that Mainnet requires an invitation and offers code entry. Users without a code can remain on Testnet, with a link to the approved early-access page when available.
3. The user pastes or enters the invite code. Bread validates it through the network's access mechanism.
4. Following successful validation, Bread completes any required Mainnet account setup and explicitly confirms the change of network.
5. The wallet clearly identifies the active network. Testnet balances and activity are never presented as Mainnet funds or history.

Code entry at the network switch is the proposed primary entry point. Its placement for first-time onboarding and restored wallets still needs a UX decision.

## Requirements

- Integrate with the network-owned invite mechanism; do not create an independent wallet-only permission system.
- Code entry should be short and copy/paste friendly. Use the agreed service format rather than hard-coding an assumed code length.
- Invalid codes, already-redeemed/expired codes where supported, and temporary verification failures have clear outcomes. Failed validation or cancellation leaves the user on Testnet without losing wallet state.
- Distinguish code acceptance from Mainnet account readiness. An interrupted setup can resume without silently consuming another invitation or claiming success before the account is usable.
- Keep network identity explicit throughout switching, funding and signing. Switching must not retarget a pending transaction, provider order or dApp request to another network.
- A code is an invitation, not a private key, recovery credential or proof of control of an existing account.

## Decisions to resolve before implementation

### Testnet state and switching back

Maintaining both network states was raised as an implementation concern. Decide whether the initial release preserves separate Testnet and Mainnet state or uses a clearly explained reset/reinitialization flow.

**Product recommendation:** preserve separate state and allow switching back where feasible. Do not silently wipe existing data. If a destructive transition is necessary, document exactly what is removed and the available recovery path, and obtain explicit user confirmation.

Also define what happens when a user switches with pending transactions or incomplete account setup.

### Access lifecycle

Confirm with the invite service:
- What access is bound to: an account, wallet, or another identity.
- Code reuse, expiry, redemption and retry behavior.
- How already-approved users regain access after restoring the wallet or changing devices.
- What withdrawal/recovery access remains if admission is revoked or temporarily unavailable.

Do not assume users need a fresh code on every switch, or that revoking admission may safely strand existing Mainnet funds.

### Enforcement and failure handling

Confirm which layer enforces admission and what the wallet must call. Hiding a switch or validating a code locally is not sufficient enforcement.

Agree server-side abuse protection and retry/error semantics; a short alphanumeric code alone does not establish brute-force resistance. Keep raw codes out of logs, telemetry and support reports.

## Acceptance checks

- [ ] A user without access can continue using Testnet.
- [ ] A valid invitation leads through the agreed Mainnet setup flow to a usable account.
- [ ] Invalid codes, interrupted validation and interrupted setup do not lose existing state or create duplicate redemption.
- [ ] The chosen network-state policy is documented and tested, including return to Testnet if supported.
- [ ] Restoration and second-device access follow the agreed admission policy without weakening account ownership checks.
- [ ] Mainnet and Testnet balances, activity, funding destinations and pending actions remain correctly separated.
- [ ] Active-network labeling is consistent with #875 across extension, iOS and Android.

## Out of scope

Referral rewards, invite-sharing campaigns, waitlist selection tooling and public launch scheduling. These are separate from the wallet access and network-switch flow.