#137 follow-up: document defect-1 and defect-2 reachability, drop unconstructible test

Defect 1 (reply()'s askAnsweredAsyncTasks returning >1 candidate): confirmed
unreachable today. Documented why in three places — hasAsyncQuestion matches
any task with a stamped turnId (not just an open question), and answer()'s
clearAsyncQuestion(turnId, false) leaves that stamp in place until the
resumed turn's own future resolves — so a second task can never reach the
same eligible state while a first one holds it. Kept the defensive
inbox-fallback branch as defence in depth against that guarantee weakening,
per review instruction; no test seam added.

Defect 2 (abandon()'s broader `matching` filter applying a stranded reply to
more than one task): matching.size() >= 2 alone IS reachable (already
covered by abandonFailsEveryPendingAsyncTicketForTheReleasedTarget) and was
a real pre-fix bug (97f6c33's parent reused one drained reply for every
matching task). But hadStrandedReply == true together with matching.size()
>= 2, at the instant abandon() runs, is not constructible through the public
API: send() and answer() are the only two sites that ever hold a target's
session lock, and both open a Rendezvous waiter for that target as the first
thing they do while holding it — so "lock held" and "waiter open" are the
same fact throughout this class, and reply()'s fast path always resolves an
open waiter directly instead of stranding. A strand can only be created
while no task is accepted, and the moment the lock is next taken, that
acceptance clears the strand again before abandon() can observe both facts
together. Documented this in abandon()'s javadoc and removed the earlier
attempt at a deterministic test for the conjunction, whose apparent failure
was an invalid premise (the "accepted" task's own acceptance silently
cleared the strand it was meant to race against), not the fix being absent.

fleetd/src/main/java/dev/ltms/fleet/msg/MessageService.java

@@ -383,9 +383,12 @@ public final class MessageService {
      * {@link Rendezvous#resolveQuestion} must keep today's {@code NO_WAITER} behaviour — questions
      * are interactive and must never be queued.
      *
-     * <p><strong>Ambiguous match also falls to the inbox.</strong> A target may have more than one
-     * open async task waiting on an answered turn — a lead can, and does, issue a second
-     * {@code fleet_send{wait:false}} at a member that is still busy. Returning whichever candidate a
+     * <p><strong>Ambiguous match also falls to the inbox.</strong> {@link #askAnsweredAsyncTasks}
+     * cannot actually return more than one entry today (see its own javadoc for why — in short,
+     * {@link #hasAsyncQuestion} keeps a target BUSY, so no second task can reach this state, for as
+     * long as an earlier one's {@code turnId} is still stamped). That is an emergent guarantee from
+     * two other facts, not one this method enforces, so this branch stays in as defence in depth
+     * rather than being removed as dead code: if it ever weakens, returning whichever candidate a
      * {@code ConcurrentHashMap} iteration reaches first would let a genuine reply complete the
      * <em>wrong</em> ticket — silently handing the lead something that reads like a correct answer to
      * a delegation the worker never touched, which is worse than a failure because the lead acts on
@@ -447,10 +450,21 @@ public final class MessageService {
      * never asked has {@code turnId == null}, so it can never match here and only ever completes
      * through the ordinary rendezvous fast path in {@link #reply}).
      *
-     * <p>Usually holds at most one entry, but not always: a target has no built-in limit of one open
-     * async task (see the {@link #reply} javadoc), so more than one task can independently reach this
-     * exact state at once. The caller decides what "more than one" means — {@link #reply} treats it
-     * as unresolvable and falls back to the inbox; {@link #abandon} picks the oldest deterministically.
+     * <p><strong>Returns at most one entry today — verified, not assumed.</strong> {@link #send}
+     * refuses to open a waiter on {@code target} while {@link #hasAsyncQuestion} is true, and that
+     * check matches ANY task whose {@code turnId} is still stamped in {@code asyncTasksByTurn} —
+     * not only while its question is still open. {@link #answer} deliberately leaves that stamp in
+     * place ({@code clearAsyncQuestion(turnId, false)}) until the resumed turn's own future actually
+     * resolves, at which point {@link #finishAsyncTask} both removes the stamp AND completes that
+     * task's future in the same call. So a second task can never reach "{@code turnId} stamped, future
+     * still open" — the exact pair this method matches on — while a first one already holds it: by
+     * the time the stamp is gone, so is the eligibility. This is an emergent property of those two
+     * facts holding together, not something this method (or its callers) enforces on its own — flip
+     * {@code forgetTurn} to {@code true} in that one {@link #answer} call and it silently stops being
+     * true, with nothing left to fail loudly. The callers below still handle "more than one" as
+     * defence in depth against exactly that, not because they exercise it today: {@link #reply}
+     * treats it as unresolvable and falls back to the inbox; {@link #abandon} would pick the oldest
+     * deterministically (its own {@code matching} list has no such guarantee — see its javadoc).
      */
     private List<Task> askAnsweredAsyncTasks(String target) {
         List<Task> candidates = new ArrayList<>();
@@ -515,13 +529,44 @@ public final class MessageService {
      * text, never the misleading "the worker session was released before it replied" (which also
      * means the snapshot/worktree recovery hint that follows it never prints once a reply exists).
      *
-     * <p><strong>At most one task gets the recovered reply.</strong> A stranded reply is one worker
-     * answer, so it can settle at most one open task on this target — never every open task, and
-     * never a guess. When more than one task is still open here (the same "more than one open async
-     * task per target" situation {@link #reply} defers on), the recovered reply goes to the
-     * <em>oldest</em> (lowest {@link Task#createdNanos}) — it has been waiting longest, so it is the
-     * one most likely to be what the reply actually answers. Every other open task keeps the ordinary
-     * {@code WORKER_FAILED} path it would take without a stranded reply at all.
+     * <p><strong>At most one task gets the recovered reply — and here, unlike {@link #reply}'s
+     * {@link #askAnsweredAsyncTasks}, {@code matching.size() >= 2} alone is reachable today.</strong>
+     * This method's {@code matching} filter has no {@code turnId != null} requirement, so it matches
+     * any plain (never-asked) open task too — and {@link #sendAsync} does not limit a target to one
+     * of those: a second {@code fleet_send{wait:false}} at a target that is still busy returns its own
+     * ticket immediately and simply parks its {@link #send} behind the target's session lock for up
+     * to {@link #ASYNC_TIMEOUT_MS}, exactly as {@code abandonFailsEveryPendingAsyncTicketForTheReleasedTarget}
+     * already proves. Before this fix, the loop below drained the strand once and then reused that
+     * same {@code Reply} for <em>every</em> task it walked past — so two open tasks really did both
+     * complete {@code REPLIED} with the same text (see the pre-fix loop in commit 97f6c33's parent).
+     * A stranded reply is one worker answer, so it can settle at most one open task on this target —
+     * never every open task, and never a guess. When more than one task is still open here, the
+     * recovered reply goes to the <em>oldest</em> (lowest {@link Task#createdNanos}) — it has been
+     * waiting longest, so it is the one most likely to be what the reply actually answers. Every
+     * other open task keeps the ordinary {@code WORKER_FAILED} path it would take without a stranded
+     * reply at all.
+     *
+     * <p><strong>{@code matching.size() >= 2} together with {@code hadStrandedReply} is a different
+     * question, and today it is defence in depth rather than a path this codebase's public API can
+     * drive.</strong> This class has exactly two sites that ever acquire a target's entry in
+     * {@code sessionLocks} — {@link #send} and {@link #answer} — and both open a {@link Rendezvous}
+     * waiter for that same target as the very first thing they do after acquiring the lock, then hold
+     * lock and waiter together for the rest of their critical section ({@link #send} also clears
+     * {@link #strandedReplies} right there, the instant it opens its waiter — before it ever enqueues
+     * delivery). So "the session lock is held" and "a live waiter is open for it" are the same fact
+     * throughout this class, and {@link #reply}'s fast path always resolves a currently-open waiter
+     * directly rather than stranding. The two facts this method wants therefore cannot be produced
+     * side by side: while the lock is held, a real reply resolves the open waiter directly and never
+     * reaches {@link #strandedReplies}; the instant the lock is free, any parked matching task's own
+     * {@link #send} that is scheduled next wins it and, by opening its waiter, clears the strand again
+     * before this method ever runs. There is no way to hold that lock open-but-unaccepted from outside
+     * {@link #send}/{@link #answer} to freeze a window in between. Constructing both facts at once
+     * through {@code sendAsync}/{@code reply}/{@code ask}/{@code answer} would need a race against
+     * virtual-thread scheduling, not a deterministic sequence — so the oldest-wins code below stays as
+     * defence in depth against a regression to that mechanism (e.g. clearing {@link #strandedReplies}
+     * on a narrower condition than "any acceptance"), not because today's test suite exercises the
+     * conjunction. {@code matching.size() >= 2} alone, without a strand, is exactly what
+     * {@code abandonFailsEveryPendingAsyncTicketForTheReleasedTarget} already covers.
      *
      * @return true if a live waiter or an async task was failed (never true for one recovered as a
      *         reply — see the note above)

fleetd/src/test/java/dev/ltms/fleet/msg/MessageServiceTest.java

@@ -688,6 +688,32 @@ class MessageServiceTest {
         assertFailedTicket(third, "agent target term_a not found");
     }
 
+    // --- #137 follow-up: abandon() must not guess when more than one task is open ---------------
+    //
+    // A test combining a genuine stranded reply (hasStrandedReply(T)==true) with two simultaneously
+    // open matching tasks was attempted here and removed after investigation showed the combination
+    // is not reachable through the public API today, not merely hard to time right:
+    //
+    // This class has exactly two call sites that ever hold a target's entry in the session-lock map
+    // (send() and answer()), and both open a Rendezvous waiter for that same target as the first thing
+    // they do after acquiring the lock, holding lock and waiter together for their whole critical
+    // section. So "the lock is held" and "a live waiter is open" are the same fact throughout this
+    // class. reply()'s fast path always resolves a currently-open waiter directly instead of
+    // stranding — so a strand can only be created while NO task is accepted (lock free), and the
+    // instant the lock is next taken (by any parked matching task's own send(), the moment it is
+    // scheduled), that acceptance clears strandedReplies again (see send()'s CB-640 comment) before
+    // abandon() can ever observe both facts together. Confirmed empirically too: an earlier version of
+    // this test stranded a reply, then created an "accepted" task (awaitWaiting()) followed by a
+    // "parked" one — and the accepted task's own acceptance silently cleared the strand it was
+    // supposed to be racing against, so the parked task came back WORKER_FAILED instead of DONE, not
+    // because the fix was missing but because the test's premise could not be constructed.
+    //
+    // The reachable half — matching.size() >= 2 alone, no strand — is exactly what
+    // abandonFailsEveryPendingAsyncTicketForTheReleasedTarget already covers (all fail, none guess).
+    // The oldest-wins code in abandon() stays as defence in depth (see its own javadoc) against a
+    // regression that would make the conjunction reachable, e.g. clearing strandedReplies on a
+    // narrower condition than "any acceptance" — not because this suite exercises it today.
+
     @Test
     void abandonDoesNotFailAnAsyncTicketWaitingForAnAnswer() throws Exception {
         String ticket = messages.sendAsync(T, "task that asks");