`winapp new --list --json` should report whether a template pack update is available

[chiaramooney]

Summary

winapp new --list --json reports the installed template pack version (TemplateVersion) but not whether a newer one exists. The CLI already computes that information — it just discards it on the JSON path — which forces JSON consumers to either prompt unconditionally or reimplement the check.

Background

--json implies --use-defaults, and --use-defaults means "keep the installed template pack". That's the right default for a non-interactive run, since installing a pack is a machine-wide dotnet new side effect. But it means a purely programmatic caller pins itself to whatever pack happens to be on the machine, forever, with no signal that it's stale.

We hit this building winapp new support into the WinApp VS Code extension. The extension calls new --list --json, and to avoid silently pinning users to a stale pack it now shows a QuickPick asking "use installed templates, or install the latest?", mapping the answer to --template-version installed|latest.

That works, but the prompt appears on every run, including the common case where the installed pack is already current. Interactive CLI users don't see that — ResolveTemplatePackAsync only prompts via PromptUpdateAsync when the pack is genuinely stale.

Proposal

Add the staleness signal to the --list --json payload:

{
  "Listed": true,
  "TemplateVersion": "0.0.6-alpha",
  "LatestTemplateVersion": "0.0.7-alpha",
  "UpdateAvailable": true,
  "Templates": [ ... ]
}

GetLatestAvailableVersionAsync already produces LatestTemplateVersion on the interactive path, so this should be mostly a matter of plumbing the value through to the JSON writer rather than new logic.

Notes on shape:

• UpdateAvailable should be false (not null) when the pack is current, and the fields should be omitted or null when the feed check couldn't run — a JSON caller shouldn't have to distinguish "no update" from "couldn't tell" by string-comparing versions.
• If the feed check would add meaningful latency to every --list --json, gating it behind an opt-in flag would work equally well for our case.

Why it helps

With this, the extension can show the update prompt only when an update actually exists, matching what an interactive winapp new user sees, and keeping the machine-wide install decision in front of the user exactly when it's meaningful. Any other programmatic consumer gets the same benefit without shelling out to dotnet new update --check-only and parsing its output.

/cc the winapp new owners (added in #686).