updated plan

organize/planning/PEER_AUTH_PLAN.md

@@ -325,18 +325,24 @@ responder's own `(runtime_session_id, library_revision, call_to_play_revision)`.
 The initiator compares them against what it has cached for that endpoint
 generation and, on any mismatch or a new session ID, schedules exactly the
 coalesced pinned pull a hint would have scheduled. A hint that was dropped,
-never sent, or discarded by rate limiting therefore converges within one ping
-interval, with no new timer, no mDNS payload growth, and no periodic full-state
-polling.
+never sent, or discarded by rate limiting therefore converges within
+`PEER_PING_IDLE_SECS + PEER_PING_INTERVAL_SECS`, because the idle threshold is
+only evaluated on interval ticks; that is 50s at the current 30s/20s settings,
+not one interval. Assert against the constants rather than a literal bound.
+Reconciliation still adds no new timer, no mDNS payload growth, and no periodic
+full-state polling, and 50s is acceptable for the rare lost-hint case.
 
-Freshness for that check must be measured from the local peer's own last pinned
-exchange with the remote peer, never from inbound activity. The current
-`ping_idle_peers` skips any peer whose `last_seen` was refreshed by traffic
-arriving from it (`update_last_seen_by_addr`), so a peer that keeps talking to
-us would suppress the very check that detects our staleness about it. Track the
-last completed outbound pinned exchange separately from `last_seen`, which
-continues to serve stale-peer pruning. Inbound traffic is not evidence of
-freshness, for the same reason it is not evidence of identity.
+Freshness is tracked per peer as `last_revision_check`, stamped only by an
+exchange that actually returned that peer's current revisions: a `Pong` or a
+completed pull. Content transfers must not stamp it. A large download is a long
+run of outbound pinned exchanges that carry no revisions, and it is exactly when
+reconciliation must not be postponed. Inbound activity must not stamp it either:
+`ping_idle_peers` currently gates on `last_seen`, which
+`update_last_seen_by_addr` refreshes from traffic arriving from that peer, so a
+peer that keeps talking to us would suppress the very check that detects our
+staleness about it. `last_seen` keeps its existing stale-peer pruning role and
+is not reused here. Inbound traffic is not evidence of freshness, for the same
+reason it is not evidence of identity.
 
 Revisions on `Pong` are a staleness signal, not content authority; the pull
 remains the authoritative step. A responder that inflates its revision only
@@ -557,8 +563,9 @@ This phase is not complete until:
 - a forged mDNS record or inbound hint cannot create/rebind/remove peer state,
   inject a library/Call-to-Play update, or bypass a pinned pull;
 - a change hint that is dropped, never sent, or rate-limited away still
-  converges within one ping interval, and inbound traffic from a peer does not
-  defer that peer's revision check;
+  converges within `PEER_PING_IDLE_SECS + PEER_PING_INTERVAL_SECS`, and neither
+  inbound traffic nor an in-flight content transfer defers that peer's revision
+  check;
 - an honest multi-source download swarms automatically and commits only the
   catalog bytes;
 - one bad source is quarantined and another source completes the chunk;