Add a WalletConnect section stating that the SDK talks to the Pera
mobile app over WalletConnect v1 through the maintained
@perawallet/walletconnect client, that v2 is not supported, and that
sessions run on Pera-hosted bridges, so no WalletConnect Cloud project
ID is needed.

Replace the signData claim that the SDK "uses signBytes behind the
scenes"; the SDK never calls it. The wallet signs each item with the
"MX" prefix, exactly like algosdk.signBytes, so signatures verify with
algosdk.verifyBytes or verifySignature.

Refs #140, #149

When wc.perawallet.app/config.json is unreachable or lists no servers,
connect() fell back to https://bridge.walletconnect.org. WalletConnect
retired that host in 2023 and it no longer resolves, so every user who
reached the fallback got a QR code against a dead bridge and a hang.

Fall back to wallet-connect-fallback.perawallet.app instead, a
Pera-controlled DNS name that can be repointed at any bridge without an
SDK release. Precedence is unchanged: the dApp `bridge` option, then
config.json, then the fallback.

Refs #104

Session-destroying paths:
- reconnectSession() no longer routes an extension reconnect failure into
  its WalletConnect catch-all, which called disconnect() and so revoked
  the origin in the wallet. A transient -32603/-32004, or a wallet on
  another network, now rejects with the transport's own error (cause at
  error.data.type rather than buried under a second wrapper) and leaves
  the approval and the stored details intact.
- A successful extension connect retires the WalletConnect pairing left
  in flight, so a QR scan that lands afterwards can no longer overwrite
  the extension session with a mobile one.
- The connect modal comes down before the provider is awaited, so its
  close button can no longer reject a connect whose later approval still
  stores the session behind the dApp's back.

Event surface:
- The WalletConnect disconnect path now clears storage and nulls the
  connector before the handler runs, matching what the README documents
  and what the extension path already did.
- Our own killSession() (in connect() and disconnect()) no longer reaches
  the dApp as a wallet-side disconnect.
- networkChanged is gated on an extension-owned session, so a dApp on a
  mobile session is not told to repoint its algod client because the
  installed extension switched network.
- dispose() is public: an instance otherwise stays subscribed to
  window.pera for the page's life, and under StrictMode/HMR the discarded
  instance swallows the events the live one should handle.

Also: signData filters non-string entries before decoding (atob(null)
decoded "null" into three plausible-looking signature bytes) and rejects
a non-array response as SIGN_DATA; isPeraProviderError duck-types instead
of relying on instanceof across realms; and the web-wallet-unavailable
stylesheet only force-expands the accordion when a single option is left,
rather than opening both the extension and QR rows uncollapsibly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds a memoized `transactionSigner` getter so Pera drops straight into
AtomicTransactionComposer and any API that accepts an algosdk signer:

  atc.addTransaction({txn, signer: peraWallet.transactionSigner});

The whole group is sent to the wallet in one signTransaction call; slots
not in indexesToSign are marked `signers: []` (ARC-0001) so the wallet
shows but does not sign them. Results are returned in indexesToSign
order, and a count mismatch from the wallet is rejected with a clear
SIGN_TRANSACTIONS error instead of reaching the composer as a corrupted
group.

The getter returns the same function on every access on purpose:
AtomicTransactionComposer batches transactions by signer identity, so a
fresh closure per access would mean one wallet prompt per transaction.

algosdk stays a peer dependency; TransactionSigner is imported as a type
only and the runtime bundle gains no algosdk symbols.

Closes #44