Fix stale claims in README and the csproj comments

CLAUDE.md

@@ -130,7 +130,7 @@ Dependency updates are handled by **Renovate**, configured in `.github/renovate.
 - **Updates arrive as one weekly batch**, Monday morning `America/Los_Angeles`. Security fixes deliberately skip that window. To pull a run forward, tick the "trigger a request for Renovate to run again" checkbox on the dependency dashboard.
 - **Nothing automerges.** `automerge: false` is global with no exceptions. A green CI run proves the repo is *consistent*, not that a bump is *correct* - and planner correctness lives in Verify snapshots, where a subtle output change surfaces as a snapshot diff to accept rather than an obvious failure.
 - **There are deliberate holds.** Before "fixing" a version that looks stale, read the rule that holds it. Each carries its reason and the condition under which to revisit. Several also mirror a comment in the corresponding `.csproj`; keep the two in sync if you change either.
-- **The dependency dashboard issue is the live inventory** of everything held back, everything queued, and everything detected. It is a better place to look than reading manifests by hand - it is how a missing hold on `swashbuckle.aspnetcore.cli` (which lives in `.config/dotnet-tools.json`, not a `.csproj`) was found.
+- **The dependency dashboard issue is the live inventory** of everything held back, everything queued, and everything detected. It is a better place to look than reading manifests by hand - it is how a missing hold on `swashbuckle.aspnetcore.cli` (which lives in `src/WebApp/.config/dotnet-tools.json` - a tool manifest under the project, not at the repo root, and not a `.csproj`) was found.
 - Holds that a migration would lift have a tracking issue named in the rule. Holds waiting on an external circumstance say explicitly that they have no issue *by design*, so an absent issue reads as a decision rather than an oversight.
 
 ### Editing the config

README.md

@@ -14,7 +14,7 @@ Why did I build my own? Well, I didn't know of these tools before I started and
 
 ### Check it out
 
-The tool is available here: https://factoriotools-5jg.pages.dev/oil-field. The planner runs entirely in your browser via .NET WebAssembly, so no blueprint data leaves your machine. There is an "Add sample" button (which drops one of my test blueprints in) and "View in FBE" buttons to view the input and output blueprints. Give it a try and let me know what you think!
+The tool is available here: https://oilfieldplanner.factorygamefan.com/oil-field. The planner runs entirely in your browser via .NET WebAssembly, so no blueprint data leaves your machine. There is an "Add sample" button (which drops one of my test blueprints in) and "View in FBE" buttons to view the input and output blueprints. Give it a try and let me know what you think!
 
 I've also attached a video of the thing in action.
 
@@ -38,7 +38,7 @@ https://user-images.githubusercontent.com/94054/224560733-35ca401f-ae51-46a9-951
 
 ### Methodology
 
-I captured 57 test blueprints from my own saves and used them for a scoring data set. If the beacon or pipe planning algorithms I tried produced better results on this data set, I considered it a better algorithm and moved forward with the idea. This iterative process allowed me to come up with several algorithm variants that are all used.
+I captured a set of test blueprints from my own saves and used them for a scoring data set (61 of them today, in [`small-list.txt`](test/FactorioTools.Test/OilField/small-list.txt)). If the beacon or pipe planning algorithms I tried produced better results on this data set, I considered it a better algorithm and moved forward with the idea. This iterative process allowed me to come up with several algorithm variants that are all used.
 
 I re-implemented FBE's pipe planner and beacon planner (with some tweaks) and wrote my own algorithms for pipe placement, pipe straitening, beacon placement, and electric pole placement. I did not try FBE's electric pole algorithm since it's not that important to have the fewest electric poles.
 

src/WebApp/WebApp.csproj

@@ -66,7 +66,7 @@
   -->
   <Target Name="PostBuild" AfterTargets="PostBuildEvent" Condition="'$(GenerateSwagger)' != 'false'">
     <Exec Command="dotnet tool restore" StandardOutputImportance="normal" />
-    <!-- DOTNET_ROLL_FORWARD=Major lets the net7-targeted Swashbuckle CLI run on net10-only hosts (CI runners), which otherwise fail with exit code 150. -->
+    <!-- DOTNET_ROLL_FORWARD=Major lets the Swashbuckle CLI run on net10-only hosts (CI runners), which otherwise fail with exit code 150. The CLI's highest shipped target is net8.0 as of 6.9.0 (it was net7.0 until #63 bumped it from 6.5.0), so it still needs a major roll-forward either way - do not assume a CLI bump makes this removable without checking its tools/ TFMs. -->
     <Exec Command="dotnet swagger tofile --output swagger.json $(OutputPath)\$(AssemblyName).dll v1" StandardOutputImportance="normal" EnvironmentVariables="DOTNET_ROLL_FORWARD=Major" />
   </Target>