feat(zap): validate zap receipts before counting

[DocNR]

What

Ports zap-receipt validation from upstream Jumble (b2f4714c), adapted to jank's services. Forged kind-9735 receipts no longer inflate stats, notifications, or the supporters list.

New lightning.validateZapReceipt(receipt) runs two NIP-57 checks:

1. Issuer (Appendix F): the receipt's pubkey must equal the nostrPubkey advertised by the recipient's LNURL-pay endpoint. Lenient when the endpoint or its nostrPubkey can't be resolved — we can't prove forgery, so we don't drop the zap (no over-filtering).
2. Preimage (Appendix E): when a preimage tag is present, sha256(preimage) must equal the bolt11 payment hash. The tag is optional, so absence isn't a failure.

The per-recipient nostrPubkey lookup is cached via DataLoader.

Wiring

• stuff-stats.service — addZapByEvent is now async: it validates, then addZap notifies subscribers itself (the async check can't feed the batch's end-of-loop notify).
• ZapNotification — gates render on an async validation result.
• fetchRecentSupporters — drops the hardcoded authors: [alby] filter in favor of real per-receipt validation (matches upstream).

jank adaptations vs upstream

• Uses jank's profileFetcher.fetchProfile / eventCache.fetchEvents / relayListService.fetchRelayList (not upstream's client.fetch*).
• Adds a unit test (lightning.validate-zap-receipt.spec.ts) — upstream shipped this with no test.

Known limitation (documented in code)

NIP-57 Appendix F also asks that the bolt11 invoice amount equal the zap request's amount tag. That cross-check is not performed (matches upstream); the issuer check is the primary forgery defense. Flagging as a possible hardening follow-up.

Gates

• Gate 1 (NIP-57): ✅ verified against the spec itself — Appendix F (issuer = LNURL nostrPubkey) + Appendix E (optional preimage→payment-hash).

• Gate 2 (signer/identity): N/A — read/validate only; nothing is signed.

• Gate 3 (realistic-relay): ✅ premise proven on live data. Fetched real kind-9735 receipts via nak and resolved each recipient's LNURL endpoint:

  recipient	provider	issuer == endpoint.nostrPubkey
  onyxvixen	walletofsatoshi.com	✅ match
  ibnimam	rizful.com	✅ match
  zap21	wallet.yakihonne.com	✅ match

  Real providers sign with their advertised nostrPubkey, so legitimate zaps pass validation; the lenient-on-unresolvable fallback protects the rest.

In-app smoke (please confirm before merge)

1. Your Notifications still show real zaps you've received (not over-filtered).
2. A note's zap count/stats still reflect real zaps.
3. (optional) A hand-forged 9735 (wrong issuer) to a WoS/Primal recipient is not counted.

Verification

• npm run build ✅ (real type check)
• npm test ✅ 862 passed / 1 skipped (incl. 5 new validation tests)
• Release note + version bump deferred to ship time (paired with feat(signer): waiting indicator + timeout for remote-signer approvals #11).

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying jank with    Cloudflare Pages

Latest commit:	9dd401a
Status:	✅  Deploy successful!
Preview URL:	https://a25e3fd6.jank-4ii.pages.dev
Branch Preview URL:	https://feat-validate-zap-receipts.jank-4ii.pages.dev

View logs