Function correct_chrono_velocity_fps 

pub fn correct_chrono_velocity_fps(
    measured_velocity_fps: f64,
    screen_distance_m: f64,
    bc: f64,
    drag_model: DragModelArg,
    mass_gr: f64,
    diameter_in: f64,
    temperature_f: f64,
    pressure_inhg: f64,
    humidity: f64,
    altitude_ft: f64,
    bc_segments: &Option<Vec<BCSegmentData>>,
) -> Result<ChronoCorrection, Box<dyn Error>>

Back-solve a true muzzle velocity from a chronograph reading taken screen_distance_m (SI meters) downrange (MBA-1377).

Most chronographs read 10-15 ft (or 25 m) downrange rather than at the muzzle, so the raw reading is slightly LOW; JBM (“Distance to Chronograph”), Lapua (V25m to V0), Ballistic AE, ColdBore, Remington Shoot!, and Hornady all correct for this. Flat-fire point-mass deceleration is monotone in muzzle velocity over the validated screen-distance band (MIN_CHRONO_DISTANCE_M..MAX_CHRONO_DISTANCE_M), so the secant method converges in a handful of iterations (McCoy, Modern Exterior Ballistics; JBM’s published calculator).

This is a pure input-side transform: velocity_at_distance_fps runs the EXISTING forward trajectory model (the same BC / drag_model / atmosphere the rest of the command is configured with) to predict the screen-distance velocity for a candidate muzzle velocity, and the candidate is iterated until that prediction matches the measured reading. Callers apply this once, before the corrected value is used for display/comparison – solve_truing_trajectory’s drop-based solves never receive a screen distance.