Alibaba began rejecting every Baxia drag with a rotating sdk_error_code while
the drag itself was provably correct: trusted events, full 258px travel,
max_fill=279, geometry matching the documented 300x34 track and 42x30 handle.
Mechanics were never the problem. Two replay defects were.

A human slide captured on the live widget and accepted by the SDK, against
what wafer was replaying:

                  human     shipped corpus
  duration        0.76s     3.07-5.42s
  speed           421px/s   48-84px/s
  release         rx 1.26   clamped to 1.0
  event rate      44/s      34-49/s

Event rate already matched, so this was never sampling. The corpus is simply
~7x too slow: mousse's own instructions call for "confident and fast" and the
recordings did not follow them, so wafer was replaying mis-recorded data
faithfully. `_replay_drag(full_track_slide=True)` now compresses the pressed
phase into _SLIDE_DRAG_SECONDS and subsamples to _SLIDE_EVENT_RATE. The
pre-mousedown hover is untouched -- that is deliberate thinking time and the
human's was a comparable ~1s. Subsampling is load-bearing rather than
cosmetic: CDP move dispatch costs ~8-10ms, so a 250-event drag cannot be
emitted in 0.76s and the compression would silently not happen.

The clamp is the second defect. It constrained every pressed sample to the
slider interval, erasing the overshoot-and-correction that all 15 recordings
contain and that docs/ref-baxia.md lists as behavioral signal 3 -- leaving a
drag that decelerates onto the endpoint and never passes it. The accepted
human slide released at rx=1.26, 64px beyond full travel, so the release
needed freeing too, not just the intermediate samples.

Both changes ride one flag, set only at the Baxia call site. That scoping is
required, not tidy: `_replay_drag` is shared with GeeTest, whose end_x is a
CV-computed notch offset with no physical stop, and 6 of the 26 shipped
puzzle recordings release past their own target (up to rx=1.074). An
unconditional clamp removal would drop the piece past the notch and silently
regress a solver documented at 12/12. The default path still clamps.

slide_016.csv is the captured human reference. Mousse now rejects a take
outside 0.35-1.40s at record time, states the target pace on screen, and says
to overshoot -- the corpus was saved mis-paced because nothing checked.
Re-recording all 16 at true slide pace is the durable fix; compressing the
old traces is the interim one.

Live on gated alibaba.com/trade/search, list and grid views: a 10-query burst
returned 10/10 real result pages, TMD triggered and solved on the first
request with the earned x5sec replaying the rest at ~2s each; a later 6-query
burst solved on the first drag with zero rejections. Before: 0/2 requests,
0/6 drags accepted.

Not covered: AliExpress is not gating at present, so the same path is
unverified there, and TMD's action=captcharecaptcha variant routes to the
reCAPTCHA solver and is untouched by this.