Settle out-of-band roll-heights from a same-roll adjacent frame (#74)

[NewGraphEnvironment]

Summary

• Third witness for out-of-band flying_height: where no logbook settles a roll-height, a frame one number away on the same roll, lens and scale, itself in band, whose height the catalogue's stands in an exact relation to (×10, ÷10, ÷100, ×10.764, one leading digit), settles it at that neighbour's height. Spacing must agree, and a logbook vetoes it only by naming a different factor. Stage 5b of data-raw/height_calibrate-lower_tail_rolls.R; fly_footprint() logic unchanged.
• The rule was fixed at the plan gate and run over all 521 roll-heights the logbook rule left excluded, in both tails. It settles 5 roll-heights / 138 frames: bc5596 204–211 (26,212 → 2,621 m) and bcb98013 frame 52 (97,924 → 7,924 m) from the issue, plus bc7675 609 → 6,096, bc87070 396 → 3,962 and bcc822 701 → 7,010 in the lower tail. A logbook row the logbook rule could not accept corroborates each lower-tail row.
• flying_height_rolls.csv gains witness and sibling_frame, and _excluded.csv gains sibling_reason. The table now reaches 1,438 frames; 1,281 slipped frames stay on ÷10.764.

Related Issues

• Closes Two #54-slipped roll-heights a sibling frame settles and no logbook does #74

The tolerance, which is the load-bearing part

bc5596 204–211 sit between 2,621 m (×10 to 2 m) and 2,438 m (×10.764 to 30 m, 0.12%). At 2% both neighbours name a relation and they name different ones. The bound comes from how the catalogue stores a 0.3048 conversion (whole metres, rounded or truncated): big − k·small ∈ [−(1 + k/2), k + 1/2]. Loosening it makes the generator's control stop; this was shown by mutation, with the CSVs left untouched.

Two corrections were made during the run, recorded in the note and the archive README:

• ×10.764 was added as a named upper-tail relation, because without it the tolerance guarded nothing.
• The first bound assumed rounding only. Code-check round 3 found truncation (2,000 ft stored as 609 m), and the fix changed one outcome: bc7675 is now tabled.

A 3.28 ft/m storage also exists, found in round 4. It can only cause refusals, so it is documented rather than widened. Round 4 enumerated all 3,876 neighbour-relation pairs and found none near any bound.

Test plan

• devtools::test() passes: FAIL 0 / PASS 2397 (NOT_CRAN=true)
• Generator reruns byte-identical to the shipped CSVs; both controls pass
• Mutations go red: drop the sibling rows (3 tests), sibling height as catalogue × factor (2), gate > 1 (2), 2% tolerance (the generator stops)
• /code-check: four rounds, ended by enumeration
• CI R-CMD-check on three platforms

Notes

The issue body was edited to record the two-neighbour finding and the rule that was adopted. Nothing moves DESCRIPTION; the version bump is left to /gh-pr-merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_0115csb82i78r86GWFzwPzis