address issues with multi interpolation code

[notimaginative]

Collection of fixes for multiple issues with the multi code found by Claude AI (by way of Goober5000), plus additional issues noted by myself while checking the code. These fixes are primarily focused on the interpolation code.

These changes should not be breaking and are largely exclusive to server-side handling, but still need to be tested thoroughly before being merged. Any tests must be done with at least the server (master) using the fixes.

Setting for 26.0 milestone to allow appropriate time to test.

[JohnAFernandez]

So essentially, it looks like this should be a big improvement, and I think it's fine for it to be approved. Just so that no one accidentally merges early before testing, I am not actually hitting the approve button.

[wookieejedi]

Testing on this build reveals the skipping issue I had occasionally run into before seems fixed, too.

[chief1983]

Deploying it to an FotG standalone for testing now. In the meantime, spent some tokens on analysis and got this back.

Potential concerns
force_interpolation_mode() in ship_apply_whack — This sets _simulation_mode = true but doesn't set _packets_expended. If the ship was mid-interpolation, the next frame's simulation path (line 82) will call physics_apply_snapshot_manual to snap to the front packet position, potentially undoing the whack. Might be worth checking whether _packets_expended should also be set to true here so the ship continues simulating from its whacked position rather than snapping.

reassess_packet_index() called with no args from add_packet() — This updates the indices but skips _simulation_mode = true at line 42. If a new packet arrives and no valid interpolation window is found, the indices remain stale but simulation mode isn't engaged. This seems intentional (the guard at line 224 checks indices are valid first), but it means the ship could be stuck with old indices until the next interpolate_main call reassesses with full args. Probably fine in practice since interpolate_main runs every frame.

No _ai_comparison_frame update in the regular AI section — The code at line 2138 checks seq_num > get_ai_comparison_frame() but I don't see where set_ai_comparison_frame is called after unpacking the regular AI data. This appears to be a pre-existing issue not introduced by this PR, but worth noting since the support ship section now correctly does this.

Verdict
This is a solid, well-motivated set of fixes. The inverted interpolation scale (#1) and wrong packet indices (#2) were genuine correctness bugs that would cause visible misbehavior. The break to continue fix (#7) prevented processing ships after any gap in the array. The comparison frame tracking additions (#9, #10) close real data-ordering holes.

The code is clean, the changes are conservative, and testing feedback is positive. I'd flag concern #1 (whack + _packets_expended) and #3 (missing set_ai_comparison_frame) for the author's attention, but neither is a blocker.

Do with that what you will, doesn't sound like critical flaws or anything to me.