cert generate: guard against older CLIs that lack --if-exists / --json

Raised by a PR review of the winapp.certGenerate modernization.

Problem

buildCertGenerateArgs (src/cert-utils.ts) now unconditionally emits two options:

args.push('--if-exists', options.ifExists ?? 'error');
args.push('--json');

Both require a reasonably recent CLI. There is no minimum-version guard and no capability probe, so against an older CLI the command fails at argument parsing with an opaque error rather than a message the user can act on.

This is reachable in practice because the CLI is not always the bundled one:

• scripts/download-cli.ps1 defaults to latest, but release builds can pass an older CliReleaseTag.
• getWinappCliPath can fall back to a winapp found on PATH, which is entirely outside our control.

Note this is newly-introduced risk rather than a regression: the previous implementation passed no options at all, so it worked against any CLI.

Suggested fix

Pick whichever is cheapest to maintain:

1. Document and enforce a minimum CLI version for the extension, checked once at activation.
2. Probe capability (e.g. parse cert generate --help) and degrade gracefully — fall back to the old no-options invocation when the flags are unavailable.
3. At minimum, detect the argument-parsing failure and translate it into "your winapp CLI is too old for this command; expected >= X.Y.Z, found ".

Option 3 alone would remove the opaque-failure problem for very little code.

Related

• #242 (custom passwords)
• #243 (--output / --valid-days / --export-cer)

Start in src/cert-utils.ts at buildCertGenerateArgs, then trace how the CLI path is selected through getWinappCliPath and scripts/download-cli.ps1. Decide whether to enforce a minimum version, probe capabilities, or translate argument failures, and verify that an older external or downloaded winapp CLI produces an actionable result instead of an opaque parsing error.