Apply the version rule to the resource fallback (fixes CI on #76)

[JesseKlaasse]

Targets the branch of #76, so merging this makes #76 green.

Why #76 fails CI

Populating s_assembliesWithResources brings the resource fallback in ResolveMissingAssembly to life. That fallback returns whatever it extracts, with no version check. So Request_For_A_Newer_Version_Does_Not_Resolve_To_An_Older_One (from #74) now gets the 1.0.0.0 copy for a 2.0.0.0 request:

Failed ConsoleApp.SourceGenerator.Tests.AssemblyResolverTests.Request_For_A_Newer_Version_Does_Not_Resolve_To_An_Older_One
  Assert.Throws() Failure: No exception was thrown

There is a second problem behind it: Assembly.Load(byte[]) loads a new copy on every call, and none of them unload. Each unsatisfied request adds another copy of an assembly that is already loaded. In a compiler server that lives for hours, that is a slow leak plus duplicate type identities.

Change

• The fallback uses the same rule as the lookup above it (Satisfies: same name, at least the requested version). A copy that does not satisfy the request is still registered, but not returned.
• Each resource is unpacked at most once, by AddAssembly or by the fallback, whichever comes first (s_extractedResources, under the existing s_assembliesWithResourcesLock).
• The unused alreadyLoaded local is removed (CS0168 in the generated hoist; it shows up as a warning in every consumer's build).

The fallback still does what #75 asks for: it reaches a resource that AddAssembly has not unpacked yet. That can happen while another generator initialises on another thread, between s_assembliesWithResources.Add and the extract loop.

Tests

This also covers the Copilot note on #76: nothing exercised the fallback.

Test	#76 as is	With this
Request_For_A_Newer_Version_Does_Not_Resolve_To_An_Older_One (existing)	❌	✅
Unsatisfied_Request_Does_Not_Load_The_Embedded_Assembly_Again	❌	✅
Resource_Fallback_Unpacks_An_Embedded_Assembly_Not_Unpacked_Yet	✅	✅
Resource_Fallback_Does_Not_Resolve_To_An_Older_Version	❌	✅

The last two put the resolver in that window: they forget that one resource was unpacked, so only the fallback can reach it. Each guard was removed once to confirm its test fails:

• version check in the fallback removed → Resource_Fallback_Does_Not_Resolve_To_An_Older_Version fails;
• unpack-once removed → Unsatisfied_Request_… fails;
• s_assembliesWithResources.Add removed (the state on master) → Resource_Fallback_Unpacks_… fails.

Locally, Release as in CI (.NET SDK 10.0.300): Sandbox tests 11/11, SourceGenerator.Foundations.Tests 3/3 (net6.0, rolled forward to 8.0), 0 warnings.

🤖 Generated with Claude Code