fix(portals): count concurrent connection failures once (#1537)

* fix(portals): count concurrent connection failures once

* docs(portals): clarify failure counting after guard eviction

docs/architecture/host-connectivity-guard.md

@@ -170,10 +170,17 @@ Two more rules exist because of specific failure modes:
 
 - **Siblings are not a streak.** Catalog initialization fans out three category
   requests at once; one network hiccup failing all three is one piece of
-  evidence, not a trip. A failure counts only if its request started at or after
-  the moment the previous failure was recorded. Timestamps are millisecond
-  coarse, so this only separates siblings once a request actually took time —
-  which is precisely the expensive case worth protecting. Only a failure that
+  evidence, not a trip. Each admitted request receives a guard-wide monotonic
+  admission id. A counted failure saves the highest id admitted so far in that
+  endpoint's failure record, not just the id of the request that failed. During
+  that streak, only a request admitted beyond this boundary can add another
+  failure. This distinguishes
+  siblings from later attempts even if admission and completion all happen in
+  the same millisecond (#1438), regardless of completion order. Admission ids
+  are never reused when an endpoint's state is evicted. A recreated record has
+  no failure streak, so the first old in-flight failure can still count once;
+  its remaining siblings cannot add further links to that streak. Timestamps
+  still determine streak expiry, cooldown and trial timeout. Only a failure that
   was actually counted may trip the threshold: a sibling settling after the open
   window elapsed would otherwise start a fresh one off the existing count and
   push the half-open trial past the intended cooldown.