REQ-DEM-036's fourth cause: a short Result Length does not break carrier lock

[TGoodhew]

The question

REQ-DEM-036 lists four causes of a failure to lock, in order of likelihood, the fourth being
"Result Length too short for the format", and its acceptance criterion asks that each of the
four, injected deliberately, produce the corresponding diagnostic.

Measuring it while implementing #154: a Result Length below the format's recommendation does not
produce a failure to lock in this chain. Not at any length the settings allow, not on any format
tried, and not at any signal-to-noise ratio down to 15 dB.

evidence/req-dem-036/result-length-sweep.txt has all 56 combinations. The summary: 256-QAM,
128-cross QAM, 32-point star QAM and 16-QAM, Result Lengths from the recommendation down to four
symbols — the floor DemodSettings.Validate allows, and a sixty-fourth of the recommendation for
256-QAM. Every one locked. The worst reading anywhere is 12.14 %rms against the 25 %rms that
separates "poor" from "not locked", and most of that is the noise rather than the window: the same
format at the full recommended length reads 7.6 %rms in the same conditions.

That is REQ-DEM-002's block estimation behaving exactly as it was chosen to — one solution fitted
across the whole window, no loop to settle, four parameters fitted from very few symbols.

The EVM is not even monotonic in the window length. 256-QAM at 15 dB reads 6.25 %rms at 256 symbols
and 3.17 %rms at four. A four-symbol window is not a better measurement; it is a measurement of four
symbols, whose error vector is the spread of four points rather than of the format. That is what
is wrong with a short Result Length — it is unrepresentative, not unlocked — and it is what
Constellation.RecommendedResultLengthSymbols is really guarding.

What was implemented, and how to unroll it

Rather than widen anything or force a fixture until it failed:

• LockFault.ResultLength is reported when a demodulation has failed and the window is also
  below the format's recommendation — a contributing cause, never invented as the sole cause of a
  failure.
• The acceptance test AResultLengthTooShortForTheFormatIsNamedAsTheResultLength injects it
  alongside a filter mismatch that does break the lock, and asserts both are named.
• AShortResultLengthOnItsOwnLocksAndIsAccusedOfNothing is the paired control, and is the finding
  stated as a test: the same short window with nothing else wrong locks and is accused of nothing.
  A diagnosis that named the Result Length whenever it was short would be naming it on measurements
  that worked.

To unroll: the fourth cause is the only one of the four not injectable in isolation, and the two
tests named above are the whole of the accommodation.

What might be decided instead

1. Leave it. The diagnostic is honest, the AC is met in the only way the chain permits, and the
   evidence file records why. (What is implemented.)
2. Correct the requirement so the fourth cause reads as what it actually is — a Result Length
   too short for the format gives an unrepresentative measurement rather than a failure to lock —
   and give it its own criterion: a window shorter than the constellation has points cannot visit
   most of them, which is measurable and is a genuinely useful warning.
3. Warn on it unconditionally, whether or not the demodulation failed, as a measurement-quality
   notice separate from the lock diagnosis. This is arguably where it belongs, and REQ-DEM-031's
   Result Length advice notice already does something close.

My recommendation is (2) with (3) alongside: the requirement's own words are the thing that is
slightly off, and the useful warning is one nobody currently gets on a measurement that succeeded.
That needs a specification change, which is Tony's call.

Refs #154.