Whispr v1.1.8 — Messages flow after round-trip

Bug fix

Messages now flow after invite-link round-trip. v1.1.7 closed
the round-trip so both sides got a "X accepted your invite" banner,
but a follow-on bug stopped them from actually messaging each other:

• When B's contact_request arrived at A via Tor, A's app stored
  the request but discarded the sender's onion address. So A
  knew B was a contact but had no Tor delivery channel for them.
• When A tapped Accept on the pending banner, the
  contact_accepted ack only went over LAN — never over Tor. So B
  often never received it.
• The onion never got persisted to the ContactProvider, so even if
  it briefly worked in-session, restarting the app dropped it.

All three are fixed:

1. contact_request arrival now registers the sender's onion
   in torMsg and stores it in the pending-request record.
2. acceptPendingRequest sends contact_accepted over both LAN
   and Tor, picking whichever transports it has addresses for.
3. The chat-list Accept handler persists the onion via
   ContactProvider.saveOnionAddress, so the contact retains a
   Tor delivery channel across app restarts.

The same logic also applies to unknown-sender messages that arrive
before contact_request (rare race but possible) — onion is captured
from the first inbound message that carries one.

End-to-end test

Two devices, same or different network:

1. A shares an invite link with B.
2. B taps the link → invite banner → Add. (B now has A.)
3. A's chat list shows pending-request banner from B → Accept. (A now has B.)
4. Either side can now message the other — LAN if same Wi-Fi,
   Tor otherwise. Survives app restart.

Verification

• Architecture: arm64-v8a
• Signed: release keystore (CN=Whispr)

SHA-256: 1fe49e1441ff5d7a67a6c7a9938ccaf5ff8785b5c42f0aeab84ea1772d8dc166