docs(design): describe traversal signals as left to expire, not deleted

The discovery and traversal design documents still said both sides publish
NIP-09 deletion requests for their offer and answer after an attempt, and
listed deletion as the fallback for relays that store ephemeral kinds. Nodes
no longer send those requests. Say so, and why: a relay honouring NIP-59
deletes a gift wrap only at its p-tagged recipient's request, which would
have to be signed by the node's long-term key and would tie it to the
traversal's events. The wraps carry a NIP-40 expiration tag, so a relay that
stores them keeps them until they expire.

docs/design/fips-nostr-discovery.md

@@ -272,9 +272,16 @@ from the far side records the working remote address and completes the
 attempt.
 
 On timeout (`attempt_timeout_secs` as overall bound,
-`punch_duration_ms` as probe window), both sides issue NIP-9 deletes
-for their offer and answer events and report failure up to the
-discovery runtime's `BootstrapEvent::Failed` channel.
+`punch_duration_ms` as probe window), the attempt reports failure up
+to the discovery runtime's `BootstrapEvent::Failed` channel.
+
+Neither side publishes a NIP-9 deletion request for the offer or
+answer, on success or failure. A relay honouring NIP-59 deletes a gift
+wrap only at the request of its p-tagged recipient, so such a request
+would have to be signed by the node's routing key and would name the
+traversal's events, tying that key to them on every relay it reached.
+The wraps are ephemeral kinds carrying a NIP-40 expiration tag, so
+relays that store them at all keep them until they expire.
 
 ### Phase 5 — Adoption
 

docs/design/port-advertisement-and-nat-traversal.md

@@ -411,10 +411,14 @@ Once the path has acknowledged in both directions:
 After the attempt completes (success or failure):
 
 1. Close the relay subscription used for signaling.
-2. Optionally publish a NIP-09 deletion event referencing any
-   signaling events the peer published. Because the wraps were
-   ephemeral kinds with NIP-40 expiration tags, well-behaved relays
-   will discard them automatically without explicit deletion.
+2. Do not publish a NIP-09 deletion request for the signaling
+   events. Under NIP-59 a relay deletes a gift wrap only at the
+   request of its p-tagged recipient, so the request would be signed
+   by the recipient's long-term key and would name the traversal's
+   events, linking that key to them. The wraps are ephemeral kinds
+   with NIP-40 expiration tags: well-behaved relays discard them
+   without being asked, and a relay that stores them keeps them until
+   they expire.
 3. Discard the per-attempt punch socket if the attempt failed; a
    retry must allocate a new socket and a fresh reflexive address.
 
@@ -532,7 +536,7 @@ own.
 | Symmetric NAT (one side) | Punch timeout | Retry with port-prediction heuristics; otherwise fall back to an application-level relay |
 | Symmetric NAT (both sides) | Punch timeout | Application-level relay required |
 | Relay latency > 60 s | Stale reflexive address | Use low-latency relays; consider self-hosted relay |
-| Relay does not support ephemeral kinds | Signaling events persist | Use NIP-40 expiration + NIP-09 deletion as fallback |
+| Relay does not support ephemeral kinds | Signaling events persist | NIP-40 expiration bounds how long; no deletion request is sent (see Phase 6) |
 | Responder offline | No answer received | Initiator times out after configurable period |
 | Stale advert (responder no longer up) | Offer reaches no listener | Application-level failure suppression (see below) |
 | STUN server unreachable | No reflexive address | Fall back to alternate STUN server; fail if none reachable |