Deeper verification gap: behavioral prose and examples unverified on Getting-Started, Examples, Architecture #3

Three pages are verified only at the level of "this member exists". Their
behavioral prose has never been re-read against the FlexLib source, and their
examples have never been compiled. This is the largest remaining accuracy risk
in the repo.

Getting-Started.md, Examples.md, and Architecture.md each carry:

Every API member referenced on this page was checked against the 4.2.20
source: the member exists and is declared on the type used here. Prose
describing behavior and semantics has not been re-read against the source,
and the examples have not been compiled.

That status line is honest, which is why this is a tracked gap rather than a
bug. The concern is that member-existence checking is a much weaker guarantee
than it appears, and we now have two independent demonstrations of that.

Why member-existence verification is not enough

The 2026-08-02 adversarial review. A source-grep pass had already passed
these docs clean. Compiling them found three errors it had missed: a string
assigned to the AGCMode enum, s?.Mode on a type whose property is
DemodMode, and a float[] handler bound to a ushort[] delegate. Every
member involved existed. Every one was a compile break.

The 2026-08-02 Migration Guide sweep. Eight incorrect claims, and every
single member named on the page existed in 4.2.20. The errors were all in the
layer above existence: wrong delegate arity, a behavioral claim about a gain
curve that had not changed, and five "new in 4.2.x" attributions for things
already shipping in 4.1.5. A member-existence pass cannot catch any of these.
See 7983f65 and cdub89/SmartStreamer4#60.

Both cases share a shape: the member is real, and the sentence around it is
wrong. That is the class of error these three pages have never been checked
for, across roughly 3,600 lines and 48 C# blocks:

Blocking sub-task: a real regression from the Migration Guide fix

tools/Test-DocExamples.ps1 decides a block is a deliberate legacy sample by
looking for a v3-specific marker (Test-DocExamples.ps1:121-126):

$legacy = ($ctx -match '(before|old)\s*\(?v?3\.x') -or
          ($bodyTxt.ToLower() -match '//\s*(old|before)\s*\(?v?3')

The corrected fault-handler section introduced a block captioned **Old**:
that deliberately shows the 4.1.5 API (docs/Migration-Guide.md:48-57):

radio.HAAPI.AmplifierFault += OnAmplifierFault;

Neither pattern matches: the caption says **Old**: with no v3.x, and the
body has no // Old (v3 comment. So the block is classified as a fragment and
compiled against 4.2.20, where AmplifierFault does not exist. That is a
CS1061, which the script sorts as a real API error rather than
context-only noise.

This will fail on the first Windows-seat run and the failure is spurious. The
block is correct as written. The detection heuristic just predates the idea of
a deliberately-superseded 4.1.5 sample.

Options, roughly in order of preference:

1. Generalize the heuristic to any superseded-API caption, not just v3.
2. Add an explicit opt-out marker the script honors, which is more verbose per
   block but unambiguous.
3. Leave it and accept a known-failing block, which defeats the point of a
   blocking gate.

Also stale: the inventory documented in CLAUDE.md and the comment at
Test-DocExamples.ps1:157 both say 135 blocks with 5 deliberate v3.x skips.
Cutting the 3.x before/after samples dropped this to 126 csharp blocks with
zero v3.x skips remaining. The script itself detects legacy blocks
dynamically so it still runs correctly, but both counts should be refreshed
from an actual -ListOnly run rather than edited by hand.

Suggested order of work

1. Fix the legacy-detection regression above. It blocks everything else,
   because until it is resolved every gate run has a known false failure in it.
2. Run .\tools\Test-DocExamples.ps1 on the Windows seat and fix what it
   finds. This is the strongest gate the repo has and it has never been run
   against these three pages. Cheapest large win available.
3. Re-read behavioral prose against the source, one page at a time. Threading
   and lifecycle claims in Architecture.md are the highest risk, since they
   are the hardest for a reader to independently check and the least likely to
   surface as a compile error.
4. Promote each status line only after both the compile gate and the prose
   re-read have actually happened for that page. Per CLAUDE.md, relabeling
   is not verification.

Worth considering for step 3: an independent Codex verification sweep per
page, since two model families agreeing on a reading of the source is
meaningfully stronger evidence than one. Verified this session that Codex can
read the vendor tree outside the repo root under --sandbox read-only.

Not in scope

The corrections table in API-Reference.md was spot-checked this session and
is sound. Eight rows (Slice.Mode, Slice.InUse, Meter.Value,
Panadapter.MinDBM/MaxDBM, Radio.RemoveSlice, RequestPanadapter,
Radio.MeterList) were re-checked against the 4.1.5.39794 tree to confirm they
are genuine documentation errors rather than API changes mislabeled as such.
None of the old names existed in 4.1.5 either, and the only MeterList hits
are private methods identical in both trees. No follow-up needed there beyond a
full sweep if someone wants one.