tp: allow tangent blending across near-collinear ABC and UVW motion

[greatEndian]

Problem

Any move with simultaneous ABC (rotary) or UVW (secondary linear) motion was
rejected outright from tangent-blend consideration in tpSetupTangent(),
regardless of how small the direction change across the junction actually was.
In practice that forces a full exact stop at every corner of a 5-axis (or
UVW-carrying) program, even when the tool orientation barely changes direction
and the corner would otherwise blend smoothly.

Fix

tpSetupTangent() may now blend across ABC and/or UVW motion, gated by a new
shared helper tpCheckGroupTangent() applied once per group. For each group
the blend is allowed only when both hold:

• Direction is near-collinear — ≤ 1°, dot product on the group's unit
  tangent vector; and
• The resulting velocity jump fits that group's own acceleration limits.
  Direction alone is not sufficient: two segments can share an ABC direction
  exactly and still demand very different rates, which would let a large
  instantaneous jump through as if it were free. Computed by the chain rule
  (dGroup/dt = (group_tmag/target) * v), diffed, and checked against new
  tpGetABCAccelBounds() / tpGetUVWAccelBounds() (axis indices 3/4/5 and
  6/7/8), mirroring the existing XYZ tpGetMachineAccelBounds().

The jump is evaluated at the shared cap v = fmin(v_max1, v_max2), because
path speed is continuous across a tangent junction — the same v_max the
existing XYZ kink check already shares between both tangent vectors. Using
each side's own cap reports a phantom jump for matched-rate segments that
merely differ in commanded feed (a roughing/finishing feed change on an
otherwise tangent rotary move), forcing a needless exact stop.

Anything else — larger direction change, a jump beyond the accel budget, or
motion that starts or stops at the junction — falls back to the exact stop
that happens today. This is a conservative gate, not a speed dial: outside the
window we stop, and we never blend faster than the limits allow.

Both reject branches now also call tcSetTermCond(prev_tc, tc, TC_TERM_COND_STOP), matching the pre-existing sharp-corner check a few lines
below. Omitting it left the corner's blend-arc geometry ambiguous whenever a
rejected junction immediately followed a successfully tangent-linked segment.

TC_SPHERICAL — the internal 3D blend-arc geometry the TP creates for
out-of-plane corners, unrelated to the interpreter's U/V/W axes — keeps its
own hard reject, now via tcSphericalMotionCheck(), renamed from
tcUVWMotionCheck() which had incorrectly bundled real UVW motion into the
same blanket reject.

Testing

Build clean, cppcheck clean on the changed file.

Validated with an automated combination-matrix harness that runs each case
against the built tree, samples commanded joint velocity, and asserts two hard
physical-safety invariants across the whole trace: velocity never exceeds the
configured joint MAX_VELOCITY (+2%), and finite-differenced acceleration
never exceeds MAX_ACCELERATION (+15%, allowing for 10 ms sampling of an
exact-limit ramp).

26 cases, 0 joint-level safety failures. Coverage includes the ABC group,
the UVW group and both together; matched and mismatched rates; circular
junctions; reversals both isolated and chained; start/stop at a junction; an
8-segment collinear chain; mixed accept/reject transitions within one program;
the feed-change case above; and a near-zero-length segment for the
divide-guard.

Before/after velocity plots on a representative 5-axis demo program show the
baseline dipping at each corner and the patched run holding through.

Real-machine validation is still outstanding — everything above is sim.

Relationship to #4221

No interaction. #4221 ("tp: apply parabolic half-accel only during an actual
blend") replaced tcGetTangentialMaxAccel() with tcGetCycleMaxAccel() in the
per-cycle update functions. This patch works at planning time in
tpSetupTangent() / tpRunOptimization() / tpGetMachineAccelBounds() and
adds disjoint helpers. Different phase, disjoint APIs — though both reason
about the same physical quantity, so it seemed worth stating explicitly.

[grandixximo]

I tried to reproduce the exact stop the problem statement describes and could not, so I want to check my reading before trusting it.

Following tpSetupTangent back to its caller: on TP_ERR_FAIL the switch at tp.c:2061 returns straight away, so tpChooseBestBlend never runs and term_cond keeps whatever tcSetupState gave it, which under G64 is TC_TERM_COND_PARABOLIC. Does that not mean master already blends these corners parabolically, and what it refuses is only the tangent and arc-blend paths?

I measured it on xyzac-trt with G64 P0.5, G1 F600 X20 A5 / G1 X40 Y20 / G1 X60 Y40, so the junction is ABC motion followed by none. Same worktree and build, only tp.c swapped:

tp.c	peak vel	deepest interior dip
master	11.032	8.697, 78.8% of peak
this branch	10.000	1.901, 19.0% of peak

Sampling is 2 ms polls of current_vel over NML, so the true floor may be lower in both; the gap and its location are what I am relying on. Master exceeding the commanded 10 mm/s is what I would expect from two segments overlapping in a live parabolic blend, and this branch stopping exactly at 10.0 is what I would expect once that overlap is gone.

If that reading is right, the tcSetTermCond(prev_tc, tc, TC_TERM_COND_STOP) on the two reject paths is what creates the stop rather than removing it, and it lands on every junction the new gate turns down. prev_has != this_has catches a rotary move followed by a pure XY move, which I would expect to be the most common corner in a 5-axis program.

You give a reason for those calls: omitting them left the blend-arc geometry ambiguous when a rejected junction follows a tangent-linked segment. Would setting STOP only in that situation cover it, and let everything else fall through to tpChooseBestBlend the way it does today?

On placement: the gate runs before the arcBlendOptDepth < 2 early return, so on a config with arc-blend optimization off master returned without touching term_cond and this forces STOP there too. Is that intended?

Smaller: findAccelScale sets the scale to 0 when a bound is 0, so an axis group whose accel limit is 0 scores as free rather than as unreachable. Probably unreachable, since a group with no configured accel should carry no motion, but it is the wrong direction for a gate like this to fail.