winui-dev-workflow: generate a .slnx solution file during greenfield scaffold

97: #97

Problem

From Joe's blog post:

The first thing I noticed was that no solution file was created. The project built fine on its own, but I had to set up the .slnx manually afterward.

dotnet new winui-mvvm -n <Name> (the template our winui-dev-workflow skill uses) doesn't emit a solution file. CLI-only users don't notice; anyone who opens the result in Visual Studio does — VS will load the loose .csproj but most workflows (multi-project growth, Test Explorer, "open existing solution") assume there is one.

Proposed fix

After dotnet new winui-mvvm, the winui-dev-workflow skill should run:

dotnet new sln -n <AppName> --format slnx
dotnet sln <AppName>.slnx add <AppName>.csproj

(Adjust to whatever invocation produces a current-format .slnx on the installed SDK; fall back gracefully to legacy .sln if the SDK is too old.) This should be the default for greenfield — the agent should not need to be asked.

Related

May be subsumed by — or coordinated with — a unified "greenfield polish phase" step (see cross-cutting themes on the 97 issue).

Acceptance criteria

• winui-dev-workflow/SKILL.md "Create or Open a Project" section adds the .slnx step.
• Generated solution uses the new .slnx format where the installed SDK supports it; falls back to .sln cleanly otherwise.
• Verified end-to-end: scaffold → open in Visual Studio → solution loads with project attached, builds without changes.

Acknowledgments

Identified by Joe Finney in Building Fluent Icon Finder with the WinUI Copilot skill.

Start in winui-dev-workflow/SKILL.md, specifically the "Create or Open a Project" section, and review the existing greenfield scaffold steps. Add the solution-generation step using the installed SDK's current format with a clean legacy fallback, then verify the scaffold opens in Visual Studio with the project attached and builds without changes.