#329: a null task in answer() is not only "never an async ticket"

The comment that landed with #329 said a null task means the turn was never
an async ticket. That is wrong, and it makes the guard read as complete.

A genuine async ticket also reaches answer() with task == null. ask() runs
clearAsyncQuestion(turnId, true) in its catch block, which drops the
asyncTasksByTurn entry, while rendezvous.closeAsk(turnId) runs later, in its
finally. Between the two the ask is still answerable and the map entry is
already gone, so answer()'s lookup returns null and the ticket is stranded.

Measured with a throwaway probe firing only that first half: answer() reported
REPLIED while the ticket stayed PENDING with a null reply. The probe used
forgetTurnForTest, so it omits markAskTimedOut; that cannot change the outcome,
because askTimedOut is read only by askAnsweredAsyncTasks, which reply() never
reaches while answer()'s own waiter is live.

Open as fleetd #334. The comment now says so.

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

@@ -1037,9 +1037,22 @@ public final class MessageService {
                 // it using whatever turnId it now reads. The #282 chained-ask case is unaffected
                 // because it is still gated purely by result.outcome() == QUESTION above, which does
                 // not depend on this lookup — widening what "task" means here cannot complete a ticket
-                // the chained ask deliberately left open. When task is null (this was never an async
-                // ticket — a blocking fleet_ask's answer() call has no Task at all), there is nothing
-                // to complete, matching the old lookup-miss behaviour.
+                // the chained ask deliberately left open.
+                //
+                // A null task is NOT only "this was never an async ticket". That reading was in this
+                // comment when #329 merged and it is wrong. A genuine async ticket also lands here
+                // with task == null, because ask()'s timeout path runs clearAsyncQuestion(turnId,
+                // true) — which drops the asyncTasksByTurn entry — in its catch block, while
+                // rendezvous.closeAsk(turnId) runs later, in its finally. Between those two the ask
+                // is still answerable but the map entry is already gone, so the lookup at :991
+                // returns null and this ticket is never completed. Measured on 2026-09-04: a probe
+                // firing only that first half before answer() runs printed
+                // "answer=REPLIED phase=PENDING reply=null" — the same stranded ticket #329 set out
+                // to fix, one step earlier in the same race. The probe used forgetTurnForTest, which
+                // omits ask()'s markAskTimedOut; that cannot change the outcome, because askTimedOut
+                // is read only by askAnsweredAsyncTasks, and reply() never reaches it while this
+                // method's own waiter is live. So #329 narrows this window rather than closing it.
+                // Open as fleetd #334 — do not read this guard as complete.
                 if (result.outcome() != Outcome.QUESTION && task != null) {
                     finishAsyncTask(task, result);
                 }