Features: stopping a member fails its ticket even mid-fleet_ask (#275)

11-Features.md

@@ -1174,6 +1174,22 @@ The flip side is the honest limitation: the new state is recorded *before* the b
 if all three attempts throw, the tickets stay pending and no later tick retries. That path logs at WARN
 and has its own test — it is a known edge, not an oversight. The retries also carry no backoff.
 
+**Stopping a member also fails its ticket now, even mid-`fleet_ask` (fleetd #275).** There are two
+ways a ticket loses its member, and they are not the same event. Health reporting `GONE` is a
+**guess** read off the live agent list; `fleet_stop` or the idle reaper releasing a session is a
+**teardown the daemon performed**, so it is certain. The sweep now takes a flag that says which one
+it is. On a certain teardown it also fails a ticket parked in `fleet_ask` — the member is gone, so
+nobody can ever answer that question — and closes the reverse rendezvous behind it. On a health
+guess it still skips an asking ticket, because the member may be answerable by a live lead and a
+guess must not kill it.
+
+**Gotcha for #275.** The health path is deliberately left unable to self-heal one narrow case: a
+member goes `GONE` while its session stays in the roster, its `fleet_ask` then lapses on its own,
+and nothing re-fires the sweep — the transition already fired once, and `FleetHealth.decide`
+returns `GONE` before it could ever return `DELEGATION_ORPHANED`. That is filed as fleetd #280, and
+whether it is reachable at all depends on whether such a session is eventually released anyway,
+which has not been checked.
+
 ---
 
 ## Tell a usage-limit refusal from a real reply