Automated Issue Completion — decisions taken unattended, 2026-09-07

[TGoodhew]

Decisions taken without Tony present, on 2026-09-07, while working REQ-NFR-025 / #410. He asked
that anything I would otherwise have stopped to ask about be answered with my recommendation and
recorded here rather than left blocking.

The measurement that prompted all of this

artifacts/coldstart/coldstart-TG-W11VM-20260907-133247.log — the first valid cold-start figure.
A clean VMware Windows 11 VM, never had OpenVSA, NGen finished, virtual NVMe SSD.

phase	cold	warm (mean of 4)	cold penalty
window (process start → main window)	2.43 s	0.60 s	+1.83 s
+menu	0.64 s	0.53 s	+0.11 s
+connect	0.02 s	0.02 s	0.00 s
+first frame	0.35 s	0.28 s	+0.07 s
total	3.43 s	1.42 s

NOT MET: 3.43 s against 3.00 s. 91 % of the penalty is before a window exists, so the front-end
registry, ConnectAsync, the capabilities query and the first FFT are all cleared — the cost is
loading assemblies, and the lever is reading fewer bytes.

Decision 1 — split RegisterAccent, so the unused theme assembly never loads (DONE)

Measured, not guessed. Process.Modules cannot answer this — the CLR does not put managed
assemblies in the PEB loader list on .NET Framework, so it reports only OpenVSA.exe and nothing
else. Subscribing to AppDomain.AssemblyLoad and building a ShellWindow the way the test host
does gives the real ordered list. It showed:

0.444  4,470,784  Syncfusion.Themes.FluentLight.WPF
0.445  4,468,224  Syncfusion.Themes.FluentDark.WPF

One millisecond apart, i.e. from one method. ThemeCatalogue.RegisterAccent had both skins as
the two arms of a single if, and the jit resolves every type a method names when it compiles
that method, not when the arm runs. So applying either theme loaded both — 4.47 MB read from cold
disk for a skin the shell was not drawing. The shell opens Dark.

Split into RegisterDarkAccent / RegisterLightAccent, each [MethodImpl(MethodImplOptions.NoInlining)]
— the attribute is load-bearing, not a hint: inlined back into one body, both types are named again
and the loads return. Verified: Syncfusion.Themes.FluentLight.WPF no longer loads at all.

Decision 2 — do NOT gate the configuration system on an embedded key (ROLLED BACK)

ConfigurationManager costs 3.05 MB on the start-up path: System.Configuration (418 KB) then
System.Xml (2.63 MB), at 0.055 s and 0.056 s — and ~10 MB of GAC native images behind them, out
of the ~103 MB of framework native images the path touches.

I implemented and then reverted a change making SyncfusionLicense.ResolveKey prefer the
build-embedded key over appSettings when no local.secrets.config sits beside the exe (a shipped
installation, exactly). It was measured and it does not work: FftProviders.ResolveFromConfiguration
reads ConfigurationManager.AppSettings for the FFT-provider override independently, so the
configuration system loads regardless. The change was complexity plus a documented-precedence
subtlety in exchange for nothing, so it is gone. git checkout on SyncfusionLicense.cs, no trace
left.

Recommendation, for Tony: there are three appSettings overrides on or near the start-up path —
SyncfusionLicense, FftProviders (OpenVSA.Dsp) and VisaConfiguration (OpenVSA.Hal.Visa). All
three are deployment overrides that are absent in a normal install. Skipping the configuration system
when none of them is actually present would remove ~10 MB of cold read, but it needs one shared
mechanism across three layers, and any cheap test for "is the override there?" is a heuristic over
the .config text. That is a design decision, not a performance tweak, and it is his. I did not
take it. Deferring the reads does not help — the first trace is an FFT, so every one of them is on
the measured path wherever it is moved to.

Decision 3 — the harness could not see what it was there to check (DONE)

Measure-ColdStart.ps1 asked ngen display OpenVSA and reported the answer as the installation's
NGen status. It is not. ngen matches a partial assembly name, and a partial name still has to
match the simple name exactly — so OpenVSA says nothing whatever about OpenVSA.Core,
OpenVSA.Dsp, or the 21.7 MB of Syncfusion the start-up path spends most of its time reading.
The v0.1.1 log reads like a clean bill of health and is silent on everything that matters.

Now it walks every assembly beside the shell, asks about each, and prints the ones that were
missed — that list is the difference between a cold start that jits 20 MB and one that does not.
Native (unmanaged) files are counted separately so OpenVSA.Fft.Native.dll is not a false alarm
every run.

Also fixed: the log said installed : 2026-08-08 for an MSI run three weeks later. It was reporting
the shell's CreationTime, which the MSI copies from the build. It now reports the build timestamp
as built, and asks Windows for the actual install date.

What is still open on #410

The single largest unknown is whether the Syncfusion assemblies get native images at all. The
installer hangs one netfx:NativeImage on OpenVSA.exe and relies on ngen install taking the
dependency closure. That is documented behaviour, not measured behaviour, and if it is not happening
then ~20 MB is jitted on the cold launch and that is the whole of the overrun. The patched harness
answers it on the next run; nothing on this machine can, because OpenVSA is not installed here and
installing it to find out would spend a machine's coldness and change Tony's dev box. I did not.

Next step is Tony's, and he is set up for it: roll the VM back to the pre-install snapshot, build
an installer from this commit, and re-run. That gives both the new figure and the NGen coverage list
in one go.

I have not closed #410 and have not touched its acceptance criteria. The 3 s is not moving —
Tony's rule from #421 is to root-cause a failure,
never widen a tolerance.

State

Landed on main as e721257. Solution-wide suite: 2 780 tests, 0 failures — the same count as
the d3bc59f bench-verified baseline, run over the whole solution rather than one project, because
the theming and layering guards only fire that way.

Bench verification of e721257 is reported in a comment below.

[TGoodhew]

Bench verification of e721257

Both instruments live — E4406A on GPIB0::17::INSTR, E4438C at TCPIP0::192.168.1.85::inst1::INSTR
(the address that moves; it answered on .85).

suite	result	exit
--exercise	97 of 97 features exercised successfully	0
cross-validation	10 of 10 scenarios passed	0
--demod-check	25 of 25 cases came out as expected	0
shell launch/close	window up in 0.77 s, closed cleanly	0

Solution-wide unit suite: 2 780 passed, 0 failed.

Every figure matches the d3bc59f baseline, which is the point — this commit changes when an
assembly loads and what the harness reports, and should move no measurement. It did not.

Worth keeping from the cross-validation, since the numbers are on the record either way. margin
in that output is remaining headroom, not the tolerance — tolerance is |error| + margin — so
the fraction of the allowance each case actually spends is:

scenario	|error|	margin	allowance used
Noise density and the ENBW correction	1.414 dB/Hz	1.086	57 %
The comb reads flat	0.815 dB	2.185	27 %
Level of a centred tone	0.280 dB	1.720	14 %
Frequency of a tone above centre	5.47 kHz	54.53	9 %

The ENBW case is the tightest of the ten and the only one spending more than half its allowance.
Not a failure and not new, but it is the one to watch if anything in the amplitude or windowing path
moves.

[TGoodhew]

Correction — how decision 2 was actually established

SYNCFUSION_LICENSE_KEY is set on the dev machine, which I did not know when I ran the load-order
probes. It changes the reasoning behind decision 2, though not the decision.

SyncfusionLicense.ResolveKey tries the environment variable first and returns there, so on this
machine it never reached ConfigurationManager in any probe run — including the ones I described
as testing the fix. Those runs did not exercise the licence path's config read at all, and I should
not have called them a test of it.

What they do establish, by elimination, is stronger than what I claimed. System.Configuration and
System.Xml still loaded at 0.055 s in every run. The only other callers in the tree are
FftProviders (OpenVSA.Dsp) and VisaConfiguration (OpenVSA.Hal.Visa), and OpenVSA.Hal.Visa
does not load until 0.397 s — far too late. So FftProviders.ResolveFromConfiguration is
demonstrably what brings up the configuration system, rather than merely being capable of it.

The consequence for the rollback is unchanged and the ordering of any future fix is now clear:

• On a shipped install there is no environment variable, so the licence path would reach
  ConfigurationManager — but FftProviders has already loaded it by then. Gating the licence path
  alone saves nothing on either machine.
• FftProviders is therefore the one that has to be dealt with first. Fixing it alone would be
  enough on this dev machine and not enough on a shipped install; both it and SyncfusionLicense
  are needed for the ~10 MB, with VisaConfiguration behind them.

This is also a trap worth knowing for anyone measuring start-up here: a developer machine with the
licence environment variable set does not load the same assemblies as a shipped installation does.

[TGoodhew]

Decision 4 — what "Instantaneous Spectrum" means (REQ-DEM-032, #146)

The requirement names three pre-demodulation traces — Time, Spectrum, Instantaneous Spectrum — and
gives all three the same 1.2 x window. So the two spectra cannot differ by window, and the
specification does not say what else they differ by. It had to be decided to build them at all.

Taken: they differ by estimator.

• Instantaneous Spectrum — one transform of the whole window. Literally the spectrum of this
  record, transients and all, which is what makes it the one to read for a burst edge. 1024 bins of
  3.9 kHz on the test signal.
• Spectrum — the averaged magnitudes of four half-overlapped segments of that same window.
  Trades resolution for a steadier estimate, which is what makes it the one to read for a noise
  floor or a spur. 256 bins of 15.6 kHz.

Measured bin-to-bin roughness 5.30 dB against 1.32 dB, so the averaged one is demonstrably the
steadier rather than merely the differently named one. Where the window is too short to divide they
coincide, which is correct rather than a degenerate case.

Why this reading: it matches the reference product's sense of "instantaneous" as not averaged,
and it is the only distinction available once the window is fixed by the requirement. Magnitudes are
averaged rather than complex values — averaging the transforms would let segments whose phases
differ cancel, and the noise floor the trace is read for would fall by the square root of the segment
count, an estimator that reports less noise the more of it you look at.

Also decided, and smaller: Hann for both, rather than the analyser's Flat Top default
(REQ-DSP-010). A pre-demodulation spectrum is read for shape and for what lies beside the carrier,
not for the amplitude of a tone, and Flat Top would buy accuracy nobody is asking of this trace at
nearly three times the bin width. One window function for both also means the two traces differ
only by the averaging, which is the difference they exist to show.

If you disagree, the change is local: PreDemodTraces.Spectrum, and the Segments constant
above it. The tests assert the relationship (averaged is steadier, instantaneous resolves finer),
not the specific bin counts, so a different segment count does not rewrite them.

Decision 5 — the pre-demodulation traces are a family of their own

Not added to ResultTrace. REQ-DEM-080's acceptance criteria close its catalogue at fifteen and a
test asserts that count against ResultTraces.All, which was Enum.GetValues — so a new member
would have joined the catalogue silently and turned that assertion into a statement about the enum
rather than about the requirement. ResultTraces.All is now written out, and these three live in
PreDemodTrace.

The second reason is that every REQ-DEM-080 trace is cut to the Result Length and these are not:
one enumeration would make ResultTraceDomain.Sample mean two different window lengths depending on
which member you were holding.

Not done

The trace catalogue is not wired into the shell, and is not wired for the existing fifteen either, so
#146 touches no UI. Exposing pre-demodulation traces is REQ-UI work and I have not opened an issue
for it — say if you want one.

[TGoodhew]

A mistake to own — a commit boundary I broke

9a00c2d is the REQ-DEM-013 (#132) commit, and it also contains
src/OpenVSA.Demod/Analog/AnalogDemodSettings.cs and AnalogMetrics.cs — the first two files of
#127. I had started writing them while the #132 test run was in the background, then staged with
git add -A.

They compile and nothing calls them, so main was never broken and CI stayed green, but the commit
carries work its message does not describe. I did not rewrite history to fix it: the commit was
already pushed, and a force-push over a shared branch to tidy a message is a worse trade than a
note. Recorded here rather than quietly left. Everything after it was staged by path.

Decision 6 — the offset Result Length limit is refused, not clamped (REQ-DEM-013, #132)

Asking for 2 049 symbols on OQPSK with the enhancement off throws, naming the format, the limit and
the option that lifts it. The alternative — silently analysing 2 048 of them — is the exact failure
the criterion's second half exists to catch, and it would report the short window's steadiness under
the long window's name with nothing downstream able to tell.

Setting the option on a non-offset format is deliberately not an error. Settings are carried from
one format to the next, and refusing there would make changing format fail for a reason the user did
not cause.

Decision 7 — √N is asserted as a floor, not a band (REQ-DEM-013)

The criterion predicts the estimate steadies as 1/sqrt(N). Measured: 7.63x against the 4.42x
that sqrt(40000/2048) gives. That is not an error — the residual carrier estimate's spread falls
76x over the same change, which is N^1.5, the scaling of a linear phase fit. Two components
shrink with the window, so the total shrinks faster than the per-symbol statistics alone.

So the test asserts a lower bound. A two-sided band around 4.42 would be asserting that the
second mechanism does not exist.

Two related notes on the arithmetic:

• The criterion writes "variance falls as 1/sqrt(N)". Variance falls as 1/N; the standard error
  falls as 1/sqrt(N), which is the formula quoted. I measured the standard deviation and report the
  variance ratio beside it, so which reading was taken is visible. If you meant variance, the
  numbers are all there and the assertion is a one-line change.
• I got the sampling error wrong first time — wrote sqrt(2/(n-1)) where a sample standard
  deviation's is 1/sqrt(2(n-1)). That put the floor at 0.81, which an implementation that
  truncated internally and steadied nothing would have passed. It is 2.62 now, with an assertion
  keeping the floor clear of 1.0 so the test cannot quietly stop discriminating.

The short window also reads 1.37 % higher. Three explanations, two killed: a lead-in past the
generator's ramp changed nothing, and equalising the record length changed nothing (numbers came back
bit-identical). What held is the window's leading edge — inside one 40 000-symbol result the
leading 2 048 symbols read 1.49 % above an interior 2 048. That is a property of where the chain
puts the result window, not of this change, and it now has a test of its own.

Decision 8 — analog demodulation is a chain of its own (REQ-DEM-010a, #127)

Not a step in the digital chain. Those fourteen steps assume a symbol clock, a constellation and a
decision; an analog carrier has none of the three, and threading it through would be fourteen special
cases. OpenVSA.Demod.Analog shares the acquisition and the trace shape and nothing else.

Spectrum vs detector, and where the SINAD ceiling comes from. All three clean signals returned
88.05 dB to the decimal, which needed a control rather than a celebration — that is equally what
a hard-coded constant looks like, and "above 60 dB" passes either. Injected noise at three levels
takes it 88.05 → 63.98 → 44.00 → 24.02, which is 20.0 dB per decade of noise amplitude. The
ceiling is Blackman-Harris's 92 dB sidelobes, not the detector: the criterion is met with 28 dB in
hand and the figure above that belongs to the analysis window.

A judgement call in it: Spectrum uses Blackman-Harris specifically because Hann's −31.5 dB
sidelobes would put a ~40 dB ceiling on SINAD and the requirement could not be met with any
detector. That is a defensible engineering choice but it is mine, not the specification's.

Residual FM/AM is defined as what is left after the fundamental and its first five harmonics are
removed. The requirement names the metric and not its definition; five harmonics is
HarmonicsForDistortion, settable, and the same set feeds THD so the two cannot disagree about which
bins are the modulation.

Not done, deliberately

Neither #132 nor #127 touches the UI. The digital trace catalogue is not wired into the shell for its
existing fifteen traces either, so analog demodulation and the pre-demodulation traces are consistent
with it rather than half-finished. Exposing all three families is REQ-UI work and I have not opened
an issue for it — say if you want one.

[TGoodhew]

Bench verification of 1ad6229 (covers #132 and #127)

Both instruments live — E4406A GPIB0::17::INSTR, E4438C TCPIP0::192.168.1.85::inst1::INSTR.

suite	result	exit
--exercise	97 of 97 features exercised successfully	0
cross-validation	10 of 10 scenarios passed	0
--demod-check	25 of 25 cases came out as expected	0
shell launch/close	window up in 0.78 s	0

Solution-wide unit suite: 2 813 passed, 0 failed.

CI green on all three of the session's commits — 34168782001, 34170531489, 34170996661.

Unchanged from the d3bc59f baseline on every bench figure, which is the point: REQ-DEM-032
adds a window nothing reads back, REQ-DEM-013 adds a limit and an option, and REQ-DEM-010a adds
a chain nothing else calls. None of the three should move a digital measurement, and none did.

[TGoodhew]

The three interpretations are now in the shipped documentation — 3fedd18

Tony asked that they be findable in the documentation as well as here, in case he wants to change
any of them later. Two help topics, written to docs/help/ and embedded in the assembly the way
the existing four are, so the help a build carries is the help that build was written against.

Reading	Page	Why it matters
Blackman-Harris analysis window	demodulation-analog	Hann's −31.5 dB sidelobes cap SINAD near 40 dB against a 60 dB requirement — no detector whatever could meet it. Revisiting this decides whether REQ-DEM-010a is meetable, not just what the number is.
Residual FM/AM = fundamental + first five harmonics removed	demodulation-analog	The requirement names the result and does not define it.
Spectrum vs Instantaneous Spectrum = averaged vs not	demodulation-result-window	REQ-DEM-032 gives both the same window, so the difference had to be decided.

Each carries the same ⚠ An interpretation, not a specification marker, and a test counts
them — two on one page, one on the other. Presence alone would let a new reading arrive without its
warning, and would leave a stale warning behind when one was settled; a changed count means one of
those two things happened.

The pages also write down two things a user would otherwise discover the hard way: that displaying a
pre-demodulation trace cannot change a result (not what most analysers do), and that a short
Result Length reads ~1.4 % higher because of where the window starts rather than its length.

🔴 A gap found while doing it — five shipped help topics are unreachable from the shell

Six topics now ship and F1 reaches one. HelpPresentation.DefaultTopic shows
demodulation-processing-order and nothing offers the others.

Its remark read "one topic ships, so there is nothing to choose between… this constant is where
that decision will announce that it has to be made" — which was already untrue at four topics,
before today. Corrected to say the decision is now due.

Not fixed, and the reason is a boundary rather than an oversight. REQ-UI-061 fixes the menu
bar's contents as an exact list with a test that fails the build if anything is added, so a Help
submenu listing topics is that requirement's business. What choosing between topics really wants is
an index and a context — a help system — which is REQ-UI work nobody has specified.

Nothing is lost in the meantime: the pages are in docs/help/ and compiled into the assembly. It is
the shell's route to them that is missing. This is the second thing on the REQ-UI pile, beside
the trace catalogue, the pre-demodulation traces and analog demodulation all being unreachable too.
Still no issue opened for any of it — say the word.

check_project_files.py fails locally and passes in CI, benignly

Building the installer earlier used /p:Platform=x64, which creates a second bin\x64 tree beside
the plain one; the checker flags the pair because dotnet test --no-build could then run whichever
is stale. CI never builds an installer in that job, so it stays clean.

It did not affect anything measured today: every run used dotnet test without --no-build and
without an explicit platform, so it built and ran one tree consistently. Left alone rather than
deleted, because the installer build legitimately produces the second tree.

[TGoodhew]

🔴 A defect found, not a decision — REQ-DEM-066's MSK clause (637400f)

Worth reading even though nothing here needed your judgement, because it is the kind of fault a test
was actively protecting.

The build refused to report IQ Offset for MSK at all. MetricApplicability grouped it with the
axis imbalance and quadrature error, on the reasoning that "FSK and MSK are not linear modulations
of a constellation, so there is no such fit to read them out of". That is sound for REQ-DEM-067's
imbalance and skew. It is the opposite of what REQ-DEM-066 says:

Computed at symbol times, except for MSK, which uniquely uses all points rather than only symbol
instants.

The requirement stops to describe MSK's handling precisely because the metric is computed for it. A
symbol-instant fit on four clusters is weak — that is a reason to fit differently, not to drop the
row. So the metric was hidden on the one format the requirement singles out, and
FormatCatalogueTests asserted DoesNotContain("IQ Offset"), which locked the misreading in.

Both corrected. The offset is now fitted over every sample for MSK; imbalance, skew and rotation stay
on the symbol instants where REQ-DEM-067 puts them — two of six fitted numbers replaced, four left
alone. FSK keeps all four rows out, because REQ-DEM-066 says nothing about FSK and reading MSK's
exception across to it would be the same mistake in the other direction.

The control, because a passing number would not have been enough

An implementation that ignored the clause would still report something plausible. So the test
recomputes the symbol-instant fit from the same result and compares. 64-symbol blocks, 8 seeds,
injected −30 dB:

estimator	mean	rms error
all points	−29.944 dB	0.389 dB
symbol instants	−29.844 dB	1.865 dB

4.8× closer. If all points were no better, the clause would be decoration and the test says so in
its failure message.

Two things I got wrong on the way

• I joined the two Solve calls with && — the exact trap the comment four lines above warns
  about, which leaves the second out unassigned. The compiler caught it.
• The accuracy case needed 512 symbols, not 256. That is the block length
  ImpairmentMetricTests already uses for this criterion on 16-QAM, so it is not a length chosen
  until it passed — and the measured floor is written into the test either way: −29.818 at 256
  against −29.929 at 512, a proportional bias of about 1 % in magnitude that falls with the injected
  level.

Bench relevance: the --exercise suite drives MSK against the E4438C, so the new row appears in
a real measurement. Result reported below.

Solution-wide: 2 823 tests, 0 failures.

[TGoodhew]

REQ-DEM-070's FSK pair — 3d1a659

Deviation and error, taken from the fit step 8 has just finished rather than measured again, so the
deviation reported cannot disagree with the levels the symbols were decided against.

case	injected	reported	error
2FSK	250 kHz	249.999 kHz	0.000 %
2FSK	500 kHz	499.998 kHz	0.000 %
4FSK	300 kHz	299.954 kHz	0.015 %
4FSK	750 kHz	749.885 kHz	0.015 %
8FSK	700 kHz	699.881 kHz	0.017 %

🔴 A bug two levels could not have shown

I first took the outermost ideal level as LevelsPerAxis − 1, where the ladder −(M−1)…+(M−1) puts
it. The constellation's points are rms-normalised, so that is not where they sit: 4FSK read
2.2357× its injected deviation and 8FSK 4.5818× — which are √5 and √21, the rms of {1,3}
and of {1,3,5,7}, exactly the normalising factor.

2FSK passed throughout. A two-level ladder has an rms of one, so the normalisation is the
identity and the simplest case is blind to the fault; it only appears above two levels and grows with
the order. Worth remembering as a shape: the case you would naturally test first was the one case
that could not fail. It now asks the constellation for its largest ideal point instead of deriving
one.

Decision 9 — FSK error's normalisation is a reading

REQ-DEM-070 names "FSK error" and does not say what it is a percentage of. Peak deviation
is the choice, because that is the quantity beside it in the same requirement and the one a user has
in mind. An rms normalisation would give a number smaller by √2 at four levels and by more above
that, and the two conventions are not distinguishable from a single reading.

The tests check it two ways that do not depend on the convention: 0.015 % on a clean signal, and
2.09 % with the outer levels stretched 10 % — a 141× rise. So a metric wired to zero fails
whichever reading turns out to be right.

Decision 10 — a conflict between two requirements, resolved by the repo's own precedent

REQ-DEM-070 requires these two metrics. REQ-UI-053 enumerates the permitted error-summary row
labels and neither is in its list, with a test enforcing it. Omitting the metrics would break a P1
requirement that names them outright.

They are admitted the way SNR (MER) already is — that one is in the catalogue for exactly this
reason, because REQ-DEM-069 spells it out and the same list omits it. Labels follow REQ-UI-053's
own house style: short, truncated, no space where one can be avoided, the style that gives
Carr Ofst rather than "Carrier Offset". So the layout requirement is honoured even where its
enumeration is not.

The exceptions are named constants now, so admitting one is a declaration in the catalogue rather
than a quiet edit in a test.

For you: REQ-UI-053's enumerated list wants FSK Dev and FSK Err adding when the specification
is next revised. Three metrics now sit outside it.

A stale premise cleared

A test recorded three REQ-DEM-070 metrics as undeliverable because "FSK error and FSK deviation
need an FSK format … Constellation has PSK, QAM, APSK, ASK and Custom". Constellation.Fsk(order)
exists, so that blocker was already spent before today. Only pilot level is still owed, needing a
VSB format — #125.

MSK is deliberately excluded from the pair: the requirement names FSK, MSK's deviation is fixed at
half the symbol rate by the definition of the format rather than being a transmitter property worth
measuring, and its own row in that requirement is amplitude droop.

A methodology note against myself

I started a solution-wide rebuild while a bench run was in flight, and both touch the same binaries.
That run's exercise (97/97) and cross-validation (10/10) completed before the rebuild and stand; I
am not claiming its demod check as clean. A fresh bench on 3d1a659, with nothing else touching
the tree, is the authoritative verification and is reported below.

Solution-wide: 2 831 tests, 0 failures.

[TGoodhew]

Measured — and both targets are missed

1b5cc3d supplies what these targets have been waiting for since the gate was built: they sat at
AwaitingPhase because they needed the Phase 2 demodulator, which now exists. DemodMeasurements
is wired into the gate's --measure path.

requirement	target	measured
REQ-NFR-022 — 16-QAM, 4 096 symbols, 4 pts/symbol, equaliser off	≤ 50 ms	263 ms	5.3× over
REQ-NFR-023 — 1024-QAM, 4 000 symbols, equaliser on (31 symbols)	≤ 400 ms	1092 ms	2.7× over

Measured on TG-INTEL — i9-12900K, 24 logical cores, 64 GiB — which is comfortably above the
stated reference machine ("an 8-core x64 workstation with 32 GB RAM"). It is worse there.

The targets are untouched. 50 ms and 400 ms stand.

I nearly reported figures 2.9× too good

My first harness said 91 ms and 495 ms. It loaded OpenVSA's assemblies into PowerShell, and
pwsh 7.6.5 runs on .NET 10.0.11 — so it was timing a runtime the product does not ship on.
OpenVSA is net472, and a standalone .NET Framework 4.8 process gives the numbers above.

The only reason it was caught is that two of my own harnesses disagreed by 3× on the same
configuration, and each candidate was killed with a measurement rather than an argument:

• symbol count — asserted it equalled the requirement's; it did not fire. (A real hole all the
  same: the measurement had only checked > 0, and step 7 silently shortens the Result Length to
  what the record holds — so 4 096 symbols can quietly become 1 400. Now asserted.)
• FFT provider — printed it; both resolve ManagedFftProvider.
• thermal throttling — measured before and after thirty seconds of flat-out work: 261 ms then
  262 ms.
• the environment — ran both harnesses in one process; they agreed at 264 ms. That located
  the fault outside the code, and RuntimeInformation.FrameworkDescription finished it.

Two findings for the fix, before anyone starts optimising

The cost is cleanly linear in Result Length — 65.6, 64.6, 62.7, 62.5, 64.1 µs/symbol from 512 to
8 192 symbols. This is per-symbol work spread through the steps, not an algorithm that blows up.
So the work is making steps cheaper, not changing what they do — a different job from the one a
superlinear curve would have implied.

The same code is ~2.9× faster on .NET 10 than on .NET Framework 4.8 — 263 → 91 ms, and
1092 → 495 ms. A runtime migration would close most of both gaps and meet neither target on its
own. That is a decision of a different kind from "make step 8 faster", and it is Tony's.

Recorded in #441.