fix(vendor): 6b/6c review corrections — pre-send guards, accumulating staging, trade-note exemption, drag-over tab switch, full-stack sells

All thirteen findings, each anchored in recovered bytes or pc reads:

Buy All now runs retail's four PRE-SEND guards in order (pyreal and
alt-currency affordability, container and item slot capacity; strings
recovered from .rdata at 0x007b57b4/0x007b5750) — a rejected batch can
no longer destroy the staged list. Staged adds ACCUMULATE with the
5000 cap ("I can't possibly sell you that much!..." @0x007b59d8) and
the shop rows decrement/restore per RemoveFromShop. The max-value sell
rejection exempts trade notes — the raw bytes at 0x005d1add are `not`
(bitwise), not the pseudo-C's misleading `!`, and the early ret skips
the min check too. BF_RETAINED gates selling end to end (the bit was
already on ClientObject; AP-164's three claims were all false once
traced — RETIRED). Dragging over the vendor window auto-opens the
Selling tab per UpdateDragOver — with a correction to the review's own
citation: token 0x100000cd is the SELLING page, the guard is
"don't reopen the current tab." Sells are full-stack-only (three
retail sites; "Cannot sell part of a stack" @0x007b57ec) and Sell Item
acts on the global selection unconditionally. The confirm string gains
its byte-true trailing '?', dies with the session, staged-row
highlights repaint, dead guids unstage with retail's shopping-list
notice, and move-to-use no longer walks to targets the dispatch would
refuse.

AP-162 narrowed, AP-164 retired, AP-167/AP-168 filed honest.

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

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

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

@@ -411,6 +411,31 @@ public sealed class SelectionInteractionControllerTests
         Assert.Empty(h.Transport.Uses);
     }
 
+    /// <summary>
+    /// F11 (Slice 6b/6c review): a FAR target the eligibility gate will
+    /// refuse (not owned by the player, not useable) must never kick off a
+    /// speculative local approach at all — the prior <c>RequestUse</c>
+    /// ordering called <c>BeginApproach</c> before the eligibility check,
+    /// so an out-of-range unusable target still walked the player toward
+    /// it even though the dispatch immediately below was always going to
+    /// reject. The existing <see cref="RejectedWorldUseReleasesItsBusyReservation"/>
+    /// test never configured an approach at all (<c>TryGetApproach</c>
+    /// returns false unconditionally), so it could not have caught this —
+    /// this test explicitly combines "far" with "rejected."
+    /// </summary>
+    [Fact]
+    public void FarUnusableTargetIsRejectedWithoutApproaching()
+    {
+        var h = new Harness();
+        h.Query.Useable = false;
+        h.SetApproach(closeRange: false);
+
+        h.Controller.SendUse(Target);
+
+        Assert.Empty(h.Movement.Approaches);
+        Assert.Empty(h.Transport.Uses);
+    }
+
     [Fact]
     public void SynchronousMovementCallbackCannotDuplicateWorldUse()
     {