nugetfuzz: dependency staging can pair a wrong version or framework flavor yet count the reference as resolved #4093

Second finding from the full nuget.org catalog sweep with TestTools/nugetfuzz.cs (companion to #4092): when the staged dependency is a different version or framework flavor than the one the consumer was compiled against, individual types go UnknownType while the per-assembly "refs resolved" counter stays green. The resulting warnings look like decompiler findings but are corpus/staging artifacts.

Witness A - version skew, missing nested type. bclcontrib-abstract.log4net 2.0.0 was compiled against a System.Abstract 2.x with a nested enum ServiceLog/LogLevel:

.method public ... instance void Write (
    valuetype [System.Abstract]System.Abstract.ServiceLog/LogLevel level, ...)

The dependency range restored System.Abstract 1.0.0, where ServiceLog exists but the nested enum does not -> Unknown result type plus Expected I4, but got Unknown wherever the enum value is used as an integer (nearly all occurrences of that message in the sweep).

Witness B - sibling assembly from another package. tropo-webapi-mvc 1.0.1 ships only TropoCSharp.Mvc.dll; its TropoCSharp.dll reference resolves from the separate tropo-webapi 1.0.2 package, whose TropoCSharp.dll contains no TropoCSharp.Tropo.NewSession type at all.

Witness C - framework flavor. Silverlight assemblies (silverlight.4.persian.datepicker, the flowcontrols family, ...) reference System.Windows, Version=2.0.5.0. Staged against net4x reference assemblies, the desktop System.Windows.dll is found - but it is an 11-row portable-compat facade without Size, Rect, UIElement or Visibility. Enum comparisons against constants then produce every Invalid comparison between Unknown and I4 in the sweep.

Counter-check: copying the AssemblyRef-matching dependency next to the consumer (e.g. Spring.Aop.dll + the matching Spring.Core.dll) and decompiling yields zero warnings, so the decompiler side behaves correctly.

Suggestions.

1. When several versions of a dependency are cached, prefer the one closest to the consumer's AssemblyRef version instead of the first match.
2. After resolving an assembly by name, verify it actually satisfies the consumer (e.g. spot-check a referenced type); on mismatch, report the reference as unresolved rather than resolved. That routes these cases into the existing unresolved-ref noise filter instead of the actionable-warning bucket.

Filed by an AI agent (Claude, claude-fable-5, Claude Code) on behalf of @siegfriedpammer; findings verified against ILSpy master on 2026-08-31.