feat(vendor): Slice 6b/6c — move-to-use, buy staging, selling; the vendor arc is functionally complete

C1 an out-of-range Use now approaches first via the existing
client-predicted BeginApproach (Pickup's far-range shape mirrored;
retail's ItemHolder::UseObject @0x00588A80 has no range check and the
dispatch stays immediate). C2 Add-to-List stages into the Buying tab
via VendorStagingList (RemoveProfileFromList's two shapes,
pc:200497-200537), Buy All sends ONE batched 0x005F and flushes
staging on send exactly as retail does (SendShopEvent -> Flush,
pc:204075-204076 — not UseDone-gated), and X-close over a non-empty
staging list shows retail's confirm string recovered verbatim from the
binary data segment (0x007b5bd8) through the existing dialog factory.
C3 the Selling tab's list is the sole drop target (retail's single
IsAncestorOfMe gate, pc:204229-204246); VendorSellAcceptability ports
InqAcceptability with all rejection strings recovered verbatim from
the raw data segment; the sell side prices with BuyPrice (retail's
inverted naming: what the vendor PAYS) and 0x0060 carries no trailing
currency field, unlike Buy. C4 the status-bar reproduction test PASSES
against the production toolbar mount — retail's toolbar shows count +
name with the split bar and NO price parenthetical (that figure is the
vendor row's own cost text); no code change, the live gate referees.
C5 pack order verified correct, untouched.

Register: AP-161 narrowed to its two pre-existing cosmetic gaps;
AP-162 extended over Buy All; AP-164 (non-sellable bitfield
unmodeled), AP-165 (DescStackSize for _maxStackSize in the removal
test, bounded), AP-166 (purse text + pending-sell highlight cosmetic)
filed.

Clean-room complete solution: 11,482 passed / 4 skipped / 0 failed.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

tests/AcDream.App.Tests/Interaction/SelectionInteractionControllerTests.cs

@@ -430,19 +430,95 @@ public sealed class SelectionInteractionControllerTests
         Assert.Equal(0, h.Items.BusyCount);
     }
 
+    /// <summary>
+    /// C1 (Slice 6b move-to-use, docs/research/2026-08-08-slice6b-vendor-
+    /// completion-research.md Q2): an out-of-range Use kicks off the SAME
+    /// local client-predicted MoveToObject approach Pickup's far-range
+    /// branch already installs, giving the walk immediate visual feel. The
+    /// wire send is never gated on arrival — retail's
+    /// <c>ItemHolder::UseObject @ 0x00588A80</c> has no range check and
+    /// sends unconditionally, so the dispatch and the approach both happen
+    /// at click time, in that order. A later natural MoveTo completion must
+    /// not re-dispatch (Use has no post-arrival token the way Pickup does).
+    /// </summary>
     [Fact]
-    public void FarUseSendsImmediatelyWithoutClientApproachAndDoesNotRetry()
+    public void FarUseApproachesThenDispatchesImmediatelyAndDoesNotRetryOnArrival()
     {
         var h = new Harness();
         h.SetApproach(closeRange: false);
 
         h.Controller.SendUse(Target);
+
+        PlayerInteractionMovementSinkAssertSingleApproach(h, Target);
+        Assert.Equal(new[] { Target }, h.Transport.Uses);
+
         h.Controller.OnNaturalMoveToComplete();
 
-        Assert.Empty(h.Movement.Approaches);
         Assert.Equal(new[] { Target }, h.Transport.Uses);
     }
 
+    /// <summary>
+    /// C1 cancellation coverage: a second far Use command (the player picked
+    /// a new target, i.e. "moved on") supersedes the first local approach
+    /// cleanly — no exception, no missing/duplicated dispatch, no leaked
+    /// pending-pickup state (Use never arms one).
+    /// </summary>
+    [Fact]
+    public void NewFarUseCommandSupersedesThePreviousApproachCleanly()
+    {
+        const uint otherTarget = 0x7000_0099u;
+        var h = new Harness();
+        h.Objects.AddOrUpdate(new ClientObject
+        {
+            ObjectId = otherTarget,
+            Name = "Other",
+            Type = ItemType.Creature,
+            Useability = ItemUseability.Remote,
+        });
+        h.SetApproach(closeRange: false);
+
+        h.Controller.SendUse(Target);
+        h.SetApproach(closeRange: false, serverGuid: otherTarget);
+        h.Controller.SendUse(otherTarget);
+
+        Assert.Equal(2, h.Movement.Approaches.Count);
+        Assert.Equal(Target, h.Movement.Approaches[0].Target.ServerGuid);
+        Assert.Equal(otherTarget, h.Movement.Approaches[1].Target.ServerGuid);
+        Assert.Equal(new[] { Target, otherTarget }, h.Transport.Uses);
+
+        h.Controller.OnNaturalMoveToComplete();
+
+        Assert.Equal(new[] { Target, otherTarget }, h.Transport.Uses);
+    }
+
+    /// <summary>
+    /// C1 cancellation coverage: the underlying MoveTo controller cancelling
+    /// out from under a far Use's local approach (player moved away with
+    /// WASD, or any other source of <see cref="WeenieError"/>) must not
+    /// retract or duplicate the Use, which already went out unconditionally
+    /// at click time — Use holds no pending-pickup state for
+    /// <c>OnMoveToCancelled</c> to touch.
+    /// </summary>
+    [Fact]
+    public void MovingAwayDuringAFarUseApproachDoesNotAffectTheAlreadyDispatchedUse()
+    {
+        var h = new Harness();
+        h.SetApproach(closeRange: false);
+
+        h.Controller.SendUse(Target);
+        h.Controller.OnMoveToCancelled(WeenieError.ActionCancelled);
+        h.Controller.OnNaturalMoveToComplete();
+
+        Assert.Equal(new[] { Target }, h.Transport.Uses);
+    }
+
+    private static void PlayerInteractionMovementSinkAssertSingleApproach(
+        Harness h, uint expectedTarget)
+    {
+        InteractionApproach approach = Assert.Single(h.Movement.Approaches);
+        Assert.Equal(expectedTarget, approach.Target.ServerGuid);
+    }
+
     [Fact]
     public void CarriedDirectUseBypassesWorldApproachAndWaitsForUseDone()
     {