Improved Threat and Cluster trajectory prediction/projection

[daniellovell]

We currently project threat and cluster trajectories by instantiating LinearExtrapolator, which freezes an agent’s
instantaneous position and velocity and applies constant-velocity kinematics. This is cheap compute cost, but
would underestimate rapidly accelerating targets, circling and slaloming Threats, and centroid motion whenever clusters merge or split.

Current System

• LinearExtrapolator stores a single snapshot of position/velocity and extrapolates linearly, ignoring acceleration and any updates after construction.
• IPredictor captures the snapshot state in its constructor, so callers like IterativeLaunchPlanner repeatedly query a stale, constant-velocity model during its intercept iterations.
• IADS.CheckAndLaunchInterceptors and IADS.ShouldLaunchSubmunitions both create fresh LinearExtrapolator instances for cluster
  centroids and individual threats, so every launch/submunition decision inherits the constant-velocity assumption.
• Cluster tracking wraps centroid motion inside a dummy Agent, updated via raw centroid position/velocity only.
  There is no persistence of higher-order kinematics when cluster membership drifts.
• Threat behaviors inject significant accelerations (e.g., RotaryWingThreat adds evasive forces in UpdateMidCourse), but those accelerations never feed prediction.

Improved threat trajectory estimation system

1. Time-series state capture - maintain a short rolling history ( at least 3 samples) of position, velocity, and acceleration for every tracked
   threat and cluster centroid. Hook this into SimManager new-threat registration and ThreatClusterData.UpdateCentroid,
   persisting timestamps to handle variable Time.fixedDeltaTime.
2. Physics-aware predictor - Implement a new IPredictor (e.g., AdaptiveKinematicPredictor) that fits constant-acceleration
   (or alpha/beta/gamma) models from the history, defaulting to linear when data is sparse. Another idea is
   jerk estimation for violently maneuvering targets. Would want to expose tuning parameters (window length, process noise) via config.
3. Integration & API cleanup - Refactor IPredictor so predictors can access a live state provider rather than a frozen snapshot.
   Update IterativeLaunchPlanner, cluster launch flow, and submunition timing to request the
   new predictor
4. Would be nice to have some kind of gizmos to compare predicted vs actual positions over
   a horizon so we can tune filter gains and decide when to revert to linear mode.

Implementation notes

• Extend TrackFileData or add a dedicated ThreatKinematicHistory component to avoid scattering history buffers across systems.
• When cluster membership changes, recompute centroid acceleration from member histories to avoid discontinuities.