fix(csproj): add RollForward Major so the tool survives a runtime upgrade

[solrevdev]

Two commits: the fix, and the version bump it needs in order to ship.

The problem

.NET tools are framework-dependent applications. Roll-forward handles patch and minor versions automatically, but it does not cross major version boundaries.

So a user who installs seedfolder today and later moves to a machine carrying only a newer major runtime gets this, with a perfectly usable runtime listed in the error text:

You must install or update .NET to run this application.

Framework: 'Microsoft.NETCore.App', version '8.0.0' (arm64)

The following frameworks were found:
  10.0.10 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Verified, not assumed

Tested against mcr.microsoft.com/dotnet/sdk:10.0, which carries only the .NET 10 runtime. A net8.0 build of this tool is structurally the same case as a net10.0 tool on a future .NET 11 box.

Case	runtimeconfig.json	Result
No RollForward	no rollForward key	Failed, exit 150
<RollForward>Major</RollForward>	"rollForward": "Major"	Worked, crossed two majors
Installed with --allow-roll-forward	no rollForward key	Worked

Confirmed on this branch that the property reaches the build output:

{
  "runtimeOptions": {
    "tfm": "net10.0",
    "rollForward": "Major",
    ...
  }
}

Why the version bump is here

Without it the fix would never reach anyone. Walking the release job:

1. dotnet pack produces solrevdev.seedfolder.1.6.0.nupkg
2. dotnet nuget push --skip-duplicate silently skips it, because 1.6.0 is already on NuGet, and still exits 0
3. succeeded=true is written, so tag-release runs
4. tag-release finds v1.6.0 already on origin, resolving to an older commit than the one being released, and exits 1

So the result would be a red build on master and no new package. Bumped to 1.6.1, which is unused on NuGet and has no existing tag. Confirmed dotnet pack now produces solrevdev.seedfolder.1.6.1.nupkg.

Patch rather than minor: from a user's point of view the tool failed to start and now starts.

Why now

It helps immediately for anyone already on .NET 11, even while we still multi-target net8.0 through net10.0. It matters more in November, when .NET 8 and .NET 9 both reach end of support and this becomes a .NET 10 only tool. At that point roll-forward is what keeps it alive between LTS releases.

Backwards compatible. Refs #22. The blog post covering this is solrevdev/solrevdev.github.io#23.

🤖 Generated with Claude Code