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

## 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](https://github.com/microsoft/WinAppVSCE). 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:

```json
{
"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).

Start in the winapp new --list --json command path and trace ResolveTemplatePackAsync, GetLatestAvailableVersionAsync, and the JSON writer. Verify how the interactive path obtains the latest version and how the JSON payload is serialized. Done means JSON reports the latest version and update availability when the feed check succeeds, while current packs report false and unavailable checks remain distinguishable.

Written by the indexing model from the issue text.