Eye-read scaffolder refresh silently discards bare-entered values at extractor-empty cells

[braboj]

As a data maintainer, I want the anchor-helper scaffolder to warn (or preserve) when its refresh would discard a value I typed into an eye-read cell, so that a forgotten ! mark cannot silently lose part of a 132-cell read.

What

scaffold_anchor_helpers --write re-runs preserve !/? marks and refresh unmarked cells with the extractor's current prediction (ADR-048). When the maintainer enters a bare value at a cell whose prediction is — (extractor-empty), the refresh clobbers the entered value back to — with no signal. Working as documented, but it is silent data loss for a one-character marking slip.

Concrete case (S207, PR #1378): zeiss-touit-50mm-f2-8-macro max / 14.0 mm / 20S — maintainer entered 0.80 bare; eyeread --apply (run first) captured 0.80 into GT, then the canonicalization refresh reverted the cell to —, leaving file and GT disagreeing until hand-restored as 0.80!.

Why

Eye-reads are the project's Tier 1 ground truth (epic #790 / #1332); the marking convention is easy to slip on exactly the cells where the maintainer disagrees with an empty prediction — which are the highest-value corrections.

Acceptance criteria

• Refresh detects an unmarked cell whose current content differs from the extractor's prediction and either preserves it as a correction or fails loud naming the cell — silently overwriting is no longer possible
• Behavior documented in the generated eye-read.md legend text
• Regression test covering the bare-value-at-empty-prediction case

[braboj]

S209 evidence that widens this issue beyond the clobber-at-empty-cell case: the refresh also rewrites bare (silently-verified) cells whenever the extractor's prediction drifts after verification.

Reproduce (today's tree): py -m mtfdigitizer.scripts.scaffold_anchor_helpers zeiss-touit-32mm-f1-8 --check reports stale (predictions changed under the file when #1374 relabeled the 32mm max S/M assignments). Running --write produces:

-| 0.0           | 0.86  | 0.86  | 0.72  | 0.72  | 0.52! | 0.52! |
+| 0.0           | 0.88  | 0.88  | 0.73  | 0.73  | 0.52! | 0.52! |
-| 1.4           | 0.86  | 0.87  | 0.71  | 0.73  | 0.51  | 0.51  |
+| 1.4           | 0.86  | 0.88  | 0.71  | 0.73  | 0.51  | 0.51  |

Those bare cells are the maintainer's ADR-048 silent verification of the values as eye-read (0.86/0.86/0.72/0.72). The refresh replaces them with the CURRENT extractor predictions (0.88/0.88/0.73/0.73) and leaves them bare - the file then claims the maintainer verified values they never read. Worse, a later eyeread --apply would transcribe the drifted values into _ZEISS_TOUIT_32_GT, silently re-seeding maintainer GT from the extractor (the exact circularity #1332 existed to remove).

The refresh was reverted; the 32mm helpers deliberately stay --check-stale until this is fixed. Suggested direction: bare cells with a value are verified data - preserve them like ! marks (or auto-promote them to ! on first refresh); only - (no value) cells should track predictions. That also subsumes the original clobber case.

Also blocks the carried "wire scaffold_anchor_helpers --check into CI" follow-up - CI would be red on the 32mm today.

[braboj]

Second S209 finding - the drift class above is already materialized in committed history. A full reparse-vs-GT sweep of the three Touit eye-read files (maintainer asked for an eye-read vs digitization-log difference check on PR #1387) found the 12mm eye-read.md disagreeing with _ZEISS_TOUIT_12_GT on 9 bare cells (all ±0.01: max 40M@1.4, 10S@7.0, 10S@8.4; stopped 40M@1.4, 40S@2.8, 10S@5.6, 20S@5.6, 40M@8.4, 40S@11.2). The 32mm and 50mm files match their GT exactly.

Mechanism: the 12mm GT was transcribed in #1348 (S200); later scaffolder --write runs refreshed its unmarked cells to newer extractor predictions - scaffold_anchor_helpers --check reported the file "up to date" precisely because the bare cells track today's predictions instead of the values the maintainer verified. charts.py (written only by eyeread --apply) is the truth anchor.

Restored in PR #1387: the 9 cells reset to the charts.py values and marked ! so refreshes preserve them (S207 0.80! precedent); reparse now matches GT 0/396 diffs and --check stays clean. GT itself never drifted - calibration is unaffected - but the file was silently lying about what was verified, and a later eyeread --apply would have transcribed the drift into GT.

[braboj]

Maintainer ruling (PR #1387 review): bare cells SHOULD be refreshed; values that must persist carry !. The convention stays as designed - bare = tracks the current extractor prediction, ! = maintainer-locked value - and the "preserve bare cells / auto-promote to !" direction suggested two comments up is overruled.

Applied on the #791 branch: the 12mm's 9 drifted cells and the 32mm's 5 prediction-diverged cells are !-locked at their charts.py GT values; scaffold_anchor_helpers --check is clean on all three Touit anchors and file-vs-GT agreement is 0/396 family-wide. The wire---check-into-CI follow-up is unblocked.

This issue's remaining scope is the original ask only: a warning when a refresh is about to discard a bare-entered value (both at extractor-empty cells and where a prediction changed under a bare value), so the maintainer can decide whether to !-lock before the value is lost.