fix: restore min>max tolerance lost in clamp->std::clamp migration

The dumb3d->glm / utilities-simplification refactor replaced the old custom
clamp() (which tolerated Lo>Hi, returning the upper bound) with std::clamp,
where inverted bounds are undefined behaviour. Only a few sites were patched
afterwards, by hand, with std::minmax plumbing (incl. a stray `static` inside
a per-axle loop). Others silently produced wrong results in the AI braking /
acceleration path.

Add a safe_clamp() helper (normalizes inverted bounds) and use it ONLY where
Lo<=Hi cannot be proven at compile time (config min/max pairs, sign-dependent
expressions, container underflow). Sites with constant bounds or [0, x>=0]
keep std::clamp. Remove the manual std::minmax workarounds and rewrite the
damaged-track jolt code value-first.

utilities/utilities.h

@@ -248,6 +248,19 @@ template <typename T> bool is_equal(T const &Left, T const &Right, T const Epsil
 	return Left == Right;
 }
 
+// Tolerant clamp. Unlike std::clamp, this does NOT invoke undefined behaviour when
+// the bounds are inverted (Lo > Hi) - it normalizes them instead. This restores the
+// pre-refactor behaviour of the old custom clamp() for code paths where the bounds are
+// computed at runtime and can legitimately cross (e.g. AI acceleration/braking limits,
+// physics jolt calculations), where std::clamp's UB produced wrong results.
+template <typename Type_>
+constexpr Type_ safe_clamp( Type_ const Value, Type_ const Lo, Type_ const Hi )
+{
+	return ( Hi < Lo )
+		? std::clamp( Value, Hi, Lo )
+		: std::clamp( Value, Lo, Hi );
+}
+
 // keeps the provided value in specified range 0-Range, as if the range was circular buffer
 template <typename T> T clamp_circular(T Value, T const Range = T(360))
 {