Zaps find lightning addresses our relays have pruned

Zapping a post looked the author's lightning address up on our four home
relays only. Those prune old events, so anyone whose kind 0 hadn't changed
in a while (1776, Brad Mills) came back as "no Lightning address or Ark
address" — while their profile page, which also asks the index relays and
the author's own relays, showed the address right there. The zap lookup
now asks both ways at once and takes whichever carries a lightning address.

And when someone does have one but Lightning can't be paid right now, the
toast says that instead of claiming they have no address.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01VKv2uEFRR42Gp6NyqcN3A9

1 files changed, 9 insertions, 1 deletions

diff --git a/src/features/sync.js b/src/features/sync.js
index ed22322..44f5809 100644
--- a/src/features/sync.js
+++ b/src/features/sync.js
@@ -163,7 +163,15 @@ export function installSyncWallet(wallet, { outbox = syncOutbox() } = {}) {
     // broad profile relays — independent of whether cross-device sync is on.
     async nostrProfile(pkHex) {
       if (this.offline) return null;
-      return fetchNostrProfile(pkHex);
+      // Our relays prune: an old kind 0 (and the lightning address on it)
+      // may only survive on index relays or the person's own. Ask both ways
+      // at once; a lightning address from either wins.
+      const [near, deep] = await Promise.all([
+        fetchNostrProfile(pkHex).catch(() => null),
+        this.deepProfile ? this.deepProfile(pkHex).catch(() => null) : null,
+      ]);
+      const pays = (p) => p && (p.lud16 || p.lud06);
+      return pays(near) ? near : pays(deep) ? deep : near || deep;
     },
 
     // Relays to advertise in a zap request so we can later find the receipt: