[bmc08gt]

Payment requests lived only in memory in PaymentRequests, so a chat's request cards were blank after a restart or offline until a refetch came back. This stores each request in Room and loads it before the network.

Stacked on #1884, which takes Room to 48. Retarget to code/cash once that merges. iOS counterpart: code-payments/code-ios-app#1166.

• Room 48 → 49 (AutoMigration): new payment_requests table, one row per request. id_hex, chat_id_hex, version, status, ends_at and created_at are columns; request holds the serialized PaymentRequestMetadata.
• The merge from the contract runs in one INSERT … ON CONFLICT … DO UPDATE … WHERE in PaymentRequestDao.mergeIfNewer: a row is written when there is none, when the incoming version is greater, or at an equal version when the incoming status is EXPIRED and the stored one is OPEN. A stale fetch can't overwrite a newer row.
• Write-through: everything that goes through ingest() (chat pages, fetch, refetch, create, close, mark paid, Created updates) is stored, and an applied Updates stores the whole request at its new version. A failed write is logged and doesn't fail the fetch.
• Hydrate: loadChat, inChat and request(id) read the stored rows before the network call, through the existing open() and merge. A network failure leaves the stored copies showing.
• Room 49 → 50: new group_key_envelopes table, keyed by chat and own public key, holding each private group's key envelope as fetched (scheme, nonce, ciphertext, wrapper). The unwrapped key is never written. On an in-memory miss, GroupKeyEnvelopes.key() opens the stored envelope with the same scheme and wrapper checks as a fetched one, so encrypted request text opens offline; nothing stored, or an envelope that fails a check, falls back to the network. A fetch, storeNewKey or the member's own copy replaces the row. ALREADY_SET, an untrusted envelope, a wrong-key invite bundle and NO_ENVELOPE for a member drop it.
• Private-chat text stays encrypted in storage. Split keeps the sealed form it was opened from (sealedText), and the encoder writes that, not the decrypted text.
• Rows are deleted in RealChatCoordinator.clearCache(), alongside the other chat caches, so they follow the same rule as chat_metadata: wiped on account deletion, kept across a plain logout because the DB is per account.
• Leaving a group, being removed from one, and a feed sync dropping a group all call ChatMetadataDataSource.removeFromChat. In one transaction it clears membership and deletes the chat's group_key_envelopes and payment_requests rows. The chat_metadata row stays, since a left chat can still be shown. Hiding a DM is reversible and deletes nothing.
• Not stored: missing, inFlight, retry state, and the payment intent id. A share paid by payment reads back as paid by payment.
• A request of a kind the app doesn't know is stored without its kind and reads back as unsupported, which is how it renders today.
• Tests: GroupKeyEnvelopesTest (stored open offline, replace, fallback, one case per invalidation point, stored bytes equal the fetched envelope), GroupKeyEnvelopeDaoTest, PaymentRequestOfflineDecryptTest (encrypted request text opens offline after a restart, over the real database and GroupContentCrypto), PaymentRequestDaoTest (merge cases, per-chat listing, delete), PaymentRequestStorageTest (proto round trip including sealed text and unparseable bytes), PaymentRequestsStorageTest (Robolectric with the real DB: offline restart, encrypted text at rest, write-through, stale update and stale fetch, clearStored).