Live-found while validating the activation-race fix against the TBC
server: a CMSG_ACTIVATETAXI the server can't make sense of (e.g. a
stale start node vs. the player's actual position - reproduced by
requesting from a stale cached nearestNode after moving) can go
completely unanswered, no SMSG_ACTIVATETAXIREPLY at all in either
direction. Before activation was deferred to the reply,
taxiActivatePending_ being permanently stuck true didn't matter -
the speculative flight had already started regardless. Now that
activation correctly waits for the reply, a dropped one left
taxiActivatePending_ true forever, silently no-op'ing every future
activateTaxi() call (the "already pending" guard) - a permanent
soft-lock of the character's taxi system until relog.
Live-confirmed the fix: forced the drop scenario, the warning fired
at exactly 8.011s (kTaxiActivateReplyTimeoutSeconds=8.0f), pending
state cleared, and a subsequent request flew normally.
ae62001736