Reconnect hygiene: paced acks, persistent gift-wrap dedup, self-fragment sync fix (#1398)

* Reconnect hygiene: paced acks, persistent gift-wrap dedup, self-fragment sync fix

Remaining findings from the July 7 locked-phone test sessions, all rooted
in reconnect/relaunch behavior:

- All Nostr acks (READ and DELIVERED, direct and geohash) now flow through
  the paced queue that previously only throttled direct READ receipts.
  Reconnect redelivery produced 8 DELIVERED acks in under a second, which
  damus rejects ("noting too much").

- Processed gift-wrap event IDs persist across launches
  (NostrProcessedEventStore, wired through MessageDeduplicationService,
  debounced writes, wiped on the existing clear/panic paths). NIP-59
  randomizes gift-wrap timestamps, so the 24h-lookback DM subscriptions
  redeliver the same events every launch; without a cross-launch record
  each relaunch reprocessed old PMs and acks — the re-ack bursts and the
  "delivered ack for unknown mid" warnings (now debug: a stale ack is
  expected occasionally and not actionable).

- Own fragments handed back by sync replay (the deliberate RSR ttl=0
  restore path) now re-enter the gossip sync store before the self-drop.
  The fragment store is not archived, so after a relaunch our sync filter
  did not cover our own fragments and peers re-offered them every 30s
  round indefinitely; recording them stops the redelivery after one round
  while keeping assembly skipped.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Address Codex review on #1398: shared ack pacer, transient clears keep disk record

- Geohash acks are sent through short-lived NostrTransport instances
  (makeGeohashNostrTransport creates one per ack), so the per-instance ack
  queue never paced a burst. Acks now flow through a pacer shared across
  instances: Dependencies.live wires the process-wide sharedAckPacer, and
  the default Dependencies init builds an isolated pacer from the same
  injected scheduleAfter so tests keep stepping the throttle manually.

- clearNostrCaches() runs on every geohash channel switch, so it no longer
  wipes the persisted gift-wrap record (that stays on the clearAll/panic
  path). Persistence is now append-merge instead of snapshot-overwrite —
  serialized on the store's IO queue — so a transient in-memory clear
  between debounced flushes can't shrink the on-disk record either.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

bitchatTests/Services/BLEFragmentHandlerTests.swift

@@ -40,14 +40,17 @@ struct BLEFragmentHandlerTests {
     }
 
     @Test
-    func ownFragmentIsIgnored() {
+    func ownFragmentIsTrackedForSyncButNotAssembled() {
         let recorder = Recorder()
         let handler = makeHandler(recorder: recorder)
         let packet = makeFragmentPacket(sender: localPeerID, index: 0, total: 2)
 
         handler.handle(packet, from: localPeerID)
 
-        #expect(recorder.trackedPackets.isEmpty)
+        // Sync replay hands own fragments back after a relaunch; they must
+        // re-enter the sync store (so the next round's filter covers them
+        // and redelivery stops) without being reassembled.
+        #expect(recorder.trackedPackets.count == 1)
         #expect(recorder.appendedHeaders.isEmpty)
         #expect(recorder.reinjectedPackets.isEmpty)
     }