test(mem): pin "could not look" apart from "nothing there" in netstat

[h4x0r]

The question this settles

dispatch_windows_netstat_returns_ok fed a stub reader — an empty ISF over a
blank synthetic image — and asserted the call succeeds. It broke when
memf-windows went 0.3 → 0.4, and the tempting reading was that the library had
regressed.

It hadn't. memf-windows 0.4 draws exactly the distinction that matters, and
says so in the source:

// Fail loud on a failed bootstrap: an undetectable build or a build with no
// overlay must surface, never masquerade as an empty ("0 connections") result.
// Only a genuine per-object miss degrades to empty (below).

With no symbols over a blank image, the build number can't be determined, so no
_TCP_ENDPOINT overlay can be selected and nothing can be scanned. That is
"could not look", and an error is the right answer. The stale artifact was the
test's premise: it asserted success for a reader that models a failed bootstrap.

Why it matters beyond a red check

An examiner handed an empty connection table may reasonably conclude the
machine had no network connections. That's a false finding when the truth
is that the scan never ran — the difference between a finding and a fabrication
in a report.

Both halves are pinned

Asserting only the error would leave the other half free to regress, so:

test	asserts
netstat_surfaces_a_failed_bootstrap_as_an_error	undeterminable build reaches the caller as an error naming the stage that could not run
netstat_reports_a_completed_but_empty_scan_as_a_row	a scan that does run and finds nothing is not an error — it's the informational row, which must say why it's empty rather than merely being empty

One thing worth fixing upstream

The second test needed a provider a physical scan can actually traverse.
SyntheticPhysMem reports no ranges, and PhysicalMemoryProvider::total_size
derives from summing them — so it's zero, and any scan walks (0, 0) and
sees nothing. memf-core's public test builder therefore cannot exercise a scan
path at all.

Hence the local RangedMem wrapper that advertises an extent. memf-windows
carries an identical private wrapper for its own tests — exporting a ranged
synthetic provider from memf-core::test_builders would let both drop it.

The build number itself comes from an NtBuildLab fragment written into the
image, exercising the symbol-free fallback rather than a crafted ISF.

Verification

• cargo fmt --all -- --check — clean
• cargo clippy --workspace --lib --bins -- -D warnings — clean
• cargo test --workspace — 212 suites, 0 failures