The golden masters could not tell when the flight happened

[thc1006]

Two defects in the golden-master regression tests, both measured against
develop.

The baselines had no absolute-time anchor

Neither baseline stores a time axis or a launch step, and post_launch_positions
re-zeroes the origin at the first finite row, so the rocket trajectory carries no
information about when the flight happened. Displacing the whole flight later
while keeping the total step count passed every test up to 60 steps, 0.60 s, on
scenario 0 and 62 steps on scenario 1. What stopped it there was the downsampled
row count drifting outside its tolerance, not any check on time.

Scenario 0 is partly protected because pop_step is an absolute step index, so
displacing the pops with the flight brings the largest passing shift to zero.
Scenario 1 pops nothing, so it had no absolute anchor for the rocket at all
beyond the two steps STEP_COUNT_ABS_TOL allows. That matters there more than
anywhere: scenario 1 compares two arrays on two different clocks, the rocket
launch-relative and the balloons absolute from step 0, and whether a pop happens
depends on their relative phase.

Both baselines now record the launch step and both tests assert it before
comparing positions. The largest displacement that passes drops from 60 and 62
to 2, which is STEP_COUNT_ABS_TOL itself.

A test oracle that recomputed the code it was checking

test_scenario1_regression.py derived the release spacing as
int(release_interval / time_step) and its docstring called that "the
independent half, derived from the scenario file, not read back from the
environment". It is the identical float division production runs, so the test
could not detect the error class it advertised. With the truncation made visible:
an interval of 0.3 s at a 0.1 s step gives 2 in production and 2 in the oracle
where 3 is correct, and the test passes. Same at 0.7 and at 2.3.

Production now rounds, through a named _release_spacing_in_steps, and the
oracle compares in seconds so it never repeats that division. The two shipped
scenarios are unaffected: 1 / 0.01 and 0.5 / 0.01 are exact, and every committed
baseline number is byte for byte what it was.

On the baselines

Running the regenerators produced a diff on every trajectory digit, up to
0.694 mm. That is not from this change. Dumping all eight arrays with the fixed
production code and again with balloon_world.py checked out from HEAD gives
bit-identical results, so the rounding switch moves nothing here; the committed
baselines were simply taken on a different build, 700x inside the 0.5 m
tolerance. The regenerated files were discarded and the new field inserted at
the position the regenerator puts it, so the baseline diff is exactly one added
line per file with no existing byte touched.

Verification

The release-spacing test was landed against the original truncating body first
and failed there, 22 != 23. Six mutations each fail a named test, including
both baseline values and the rounding itself. Two controls survive, one of them
the rounding change measured against the shipped-values test, which proves the
claim that it is latent for the shipped scenarios rather than asserting it.

No tolerance was weakened. ruff check and ruff format --check pass on the
paths CI uses, uv lock --check is unchanged, pytest tests/ -q gives 301
passed and BPC_RUN_SLOW_TESTS=1 gives 321 passed.

Noted, not changed

_release_spacing_in_steps rounds half to even for an interval that is exactly
half a step, such as 0.25 s at 0.1 s. A scenario like that is arguably a
configuration error worth rejecting outright, which is a rules decision rather
than a test fix.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.