fix(video): recover the axis when a picture is not a whole number of ticks long (#409)

[superuser404notfound]

What this fixes

@orut34iop retested the released #413 + #415 repair on the original reporting asset and it still juddered from the first frame. The diagnosis in that retest is correct and this change is built on it: the asset is constant rate, but a picture is not a whole number of ticks long, so its sample table can only alternate between the two neighbouring counts (200202/5 ticks at a 1200000 timescale, cycling 40040/40041). The classifier demanded one identical step, read that as variable frame timing, and fell closed. Zero packets repaired.

Reproduced here before touching anything, on a fixture pair built the same way the first pair was: the engine passes the whole file through with PTS == DTS, every picture still in decode order.

The change

A two-valued ladder is read as the quantization it is.

• The cycle names the fraction. The smallest period the sampled deltas repeat under gives the cadence exactly, and a cycle only counts once it has been seen through twice, so a short run of jitter cannot pose as one.
• The rounding pattern names the phase. This is the part a whole-tick ladder cannot carry and a quantized one can, and it is not implied by anything else: the reporting asset sits on phase 2 while its reorder delay is 1. Exactly one phase of the period can reproduce the sampled window picture for picture, and if more than one does, or none, nothing is repaired.
• Ranks are placed on the lattice rather than on anchor + index * step, so the repair reproduces what the muxer would have written instead of landing a tick beside it. A whole-tick ladder takes the same path it always did, byte for byte.

Reading the phase has a second effect worth naming: the verdict no longer depends on where the sample was taken. Measured before the change, sampling the same file after a seek classified it as unrepairable; now a session that starts inside the file describes the same axis as one that starts at byte 0.

What deliberately does not change

• How far the ladder runs ahead of presentation still comes from the container header. Every alignment fits the ladder equally well, so the ladder cannot answer that question, and presentationShift already answers it from start_time with a clamp that bounds the damage to one reorder head. The lattice work only requires that the answer resolve to a whole number of pictures.
• The container index is still folded by one constant. Index entries and the packets they point at therefore cannot disagree, which is what keeps a segment boundary on its keyframe.
• A picture the lattice cannot place falls back to the rounded step, which still describes the stream to within a tick. Nothing is handed on in decode order because an arithmetic path did not close.
• Variable frame timing, a ladder with a dropped picture, and a wobble that never repeats are all still left exactly as the container delivered them, with tests to keep them that way.

Verification

A fractional twin pair, built the way @orut34iop built the first one: one encode at 1000000/33367 fps in a 1200000 timescale muxed twice, the composition offsets stream-copied away from the second. 33 packets, three coded video sequences, both writer shapes (edit list retained and lifted to non-negative timestamps).

• Every repaired packet carries the healthy twin's PTS and DTS exactly, from the head and after a seek to the second and third sequence.
• The whole-tick twin pair from fix(video): recover H.264 with missing composition offsets #411 still matches exactly, unchanged.
• swift test: 2091 tests in 296 suites, green, run against a checkout with Fixtures/ present so the file-backed suites actually execute.

Closes nothing on its own: #409 stays open for @orut34iop's retest on the original asset.