motion: axis_sync_teleop_tp_to_carte_pos resets velocity/acceleration

[is-primary-dev]

Without this, residual teleop_tp.curr_vel from an aborted jog can survive the FREE -> TELEOP transition. axis_sync_teleop_tp_to_carte_pos is called in two places: enabling motion from DISABLED, and entering teleop mode (e.g. after homing finishes). Both semantically represent the joint being at rest at the current cartesian position — leaving the trajectory planner's velocity and acceleration at stale non-zero values causes the first simple_tp_update_normal call after the sync to integrate one cycle of motion, drifting curr_pos away from the synced position.

Reproduction on a XYZZ machine where Z homes at MAX_LIMIT:

1. Home all
2. Jog Z in the minus direction
3. Release the jog key (axis_jog_abort(immediate=0) runs, leaving teleop_tp.curr_vel partially decayed but non-zero)
4. Re-home all (homing runs in FREE mode, does not touch teleop_tp)
5. Motion mode transitions FREE -> TELEOP on homing completion
6. axis_sync_teleop_tp_to_carte_pos sets curr_pos to the current (correct) cartesian position but leaves curr_vel non-zero
7. The first axis_calc_motion -> simple_tp_update_normal call integrates one cycle of motion, drifting curr_pos away
8. Result: homed Z lands offset from HOME by distance equal to the area under the velocity decay curve, not at HOME exactly

Two-line fix matching the function's documented intent.

[is-primary-dev]

Summary

axis_sync_teleop_tp_to_carte_pos updates teleop_tp.curr_pos and pos_cmd
from the cartesian command but does not reset curr_vel or curr_acc.
Both callers (enabling motion from DISABLED, and entering teleop mode via
set_operating_mode) semantically mean "joint at rest at this cartesian
position" — stale velocity from a prior aborted jog leaks through the
mode transition and causes the first post-sync simple_tp_update_normal
call to drift curr_pos away from the synced value.

Observable symptom

On a XYZZ machine where Z homes at MAX_LIMIT:

1. Home all
2. Jog Z in the minus direction
3. Release the jog key — axis_jog_abort(immediate=0) runs, leaving
   teleop_tp.curr_vel at a partially-decayed non-zero value
4. Re-home all — homing runs in FREE mode and does not touch teleop_tp
5. Motion mode transitions FREE → TELEOP on homing completion
6. axis_sync_teleop_tp_to_carte_pos sets curr_pos to the (correct)
   post-homing cartesian position but leaves curr_vel non-zero
7. The first subsequent axis_calc_motion → simple_tp_update_normal
   call integrates one cycle of motion, drifting curr_pos
8. Re-homed Z lands offset from HOME by the area under the velocity
   decay curve, not at HOME exactly

Fix

Two-line change in src/emc/motion/axis.c: reset curr_vel and
curr_acc to 0 in axis_sync_teleop_tp_to_carte_pos. Matches the
function's documented intent — both callers represent "joint at rest
at this position."

Testing

Reproduced and verified on a simulated XYZZ machine with HOME=500 for
the Z axes. Before the fix, re-homed Z landed 1-3 mm below HOME=500
with a deterministic relationship to the jog-settle timing. After the
fix, re-home consistently lands at exactly HOME with 0 mm spread over
5 cycles of jog-and-re-home.

Locally compiled against current upstream/master with the exact CI
invocation (./autogen.sh && ./configure --disable-check-runtime-deps && make -O -j<n>); build succeeded with no new warnings.