Merge nucleic/lucid-river-toad-6efj into dev

NucleicBroker/NucleicBroker.csproj

@@ -16,10 +16,20 @@
   </PropertyGroup>
 
   <PropertyGroup Condition="'$(UseWslc)' == 'true'">
-    <!-- Windows SDK 19041, matching the package's own lib TFM
-         (lib/net8.0-windows10.0.19041.0/wslcsdkcs.dll). Targeting a higher SDK revision
-         (26100) only adds a targeting-pack requirement the package does not need. -->
-    <TargetFramework>net9.0-windows10.0.19041.0</TargetFramework>
+    <!-- 26100, NOT the 19041 the package's lib folder advertises. Those disagree, and the
+         binary wins: `lib/net8.0-windows10.0.19041.0/wslcsdkcs.dll` is itself compiled against
+         Microsoft.Windows.SDK.NET 10.0.26100.79, so a 19041 targeting pack cannot load it —
+         `error CS1705: ... uses 'Microsoft.Windows.SDK.NET, Version=10.0.26100.79' which has a
+         higher version than referenced assembly ... 10.0.19041.38`. Matching the folder name
+         looks right and does not build. -->
+    <TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
+    <!-- The TFM alone selects a targeting pack by MAJOR revision only, and the .NET 9 SDK's
+         default for 26100 is 10.0.26100.38 — still below the .79 wslcsdkcs was built against,
+         so CS1705 survives the TFM bump. This pins the projection itself. .80 rather than the
+         .79 the error names because .79 was never published to nuget.org; the constraint is a
+         floor, so the next one up satisfies it. Raise it, never lower it, if a package bump
+         moves the floor again. -->
+    <WindowsSdkPackageVersion>10.0.26100.80</WindowsSdkPackageVersion>
     <DefineConstants>$(DefineConstants);USE_WSLC</DefineConstants>
   </PropertyGroup>