fix(vendor): evidence-based pass — max-first stack ceiling; the local player resolves never-animated MoveTo targets

Both chains pinned by the live [vendor-diag] run (vendor-diag.log)
after three code-reading rounds each failed:

The split bar: ACE serializes descStackSize=1 for EVERY browse row
(live wire, log 343-348) — the R1-era "ACE never populates desc"
claim is retracted with the line quoted. Retail's vendor sites read
pwd._maxStackSize directly (four sites, incl. UpdateItemsList
@0x004c1ea0 stamping min(remaining, _maxStackSize));
ResolveAuthoredStackSize flips to max-first for its vendor-only
consumers. Taper ceiling 1000, scarab 100, seed 1 for exempt.
Pricing still reads the desc (per-1 values on ACE).

Walk-to-use: the local player's getObjectA seam was bound to
TryGetPhysicsHost, which resolves only INSTALLED physics hosts — a
never-animated vendor has none, so TargetManager.SetTarget got null,
the MoveToObject armed with zero nodes, and UseTime never dispatched.
The log's natural=False completions were the user's own movement keys
(retail-correct input-edge cancels); attempt 4 worked because the
greeting animation had installed a host. RuntimePhysicsState gains
the retail CObjectMaint::GetObjectA seam (bound canonical resolver
with installed-host fallback); the graphical host binds the SAME
lazy-minimal-host resolver every remote already uses — whose own doc
comment names this exact never-animated hazard. The reservation
release was already correct (2b premise refuted with evidence); the
production-wiring invariants are now pinned by four new tests
including the pre-fix pathology as a permanent sabotage control.

AP-169 rewritten a second time, honestly. The [vendor-diag] probe
family (ACDREAM_DUMP_VENDOR) lands env-gated for future live triage.

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

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

src/AcDream.Runtime/Gameplay/RuntimeLocalPlayerPhysicsPublicationState.cs

@@ -296,9 +296,24 @@ internal sealed class RuntimeLocalPlayerPhysicsPublicationState : IDisposable
             minterpMaxSpeed: () => motion.GetAdjustedMaxSpeed(),
             curTime: () => controller.SimTimeSeconds,
             physicsTimerTime: () => controller.SimTimeSeconds,
-            getObjectA: id => _physics.TryGetPhysicsHost(id, out var host)
-                ? host
-                : null,
+            // 2026-08-08 vendor-approach root cause: this seam is retail's
+            // CObjectMaint::GetObjectA — it must resolve ANY in-world object
+            // so TargetManager.SetTarget's add_voyeur can deliver the
+            // immediate initial snapshot that a deferred MoveToObject/
+            // TurnToObject needs before it queues a single node (UseTime's
+            // object-move gate stays closed until that first
+            // HandleUpdateTarget). The previous binding went straight to
+            // _physics.TryGetPhysicsHost, which answers only entities whose
+            // host is ALREADY installed (remote-motion-bound movers) — a
+            // never-animated NPC/static target resolved to null, add_voyeur
+            // never ran, and the armed approach sat inert (no nodes, no
+            // movement, no completion) until user input or the 10 s
+            // staleness timeout cancelled it. ResolveObjectTableHost routes
+            // through the host-bound canonical resolver (the SAME
+            // lazy-minimal-host lookup every remote host's GetObjectA uses)
+            // and falls back to the exact installed-host lookup when no
+            // resolver is bound (no-window hosts).
+            getObjectA: _physics.ResolveObjectTableHost,
             // C3c: the [autowalk-target]/[autowalk-end] probes moved here
             // with controller construction (previously App-side in
             // PlayerModeController.BuildControllerAndCamera); they stay on