cert generate --publisher accepts malformed DNs and silently generates a mismatched certificate

[chiaramooney]

cert generate --publisher accepts malformed values and silently produces a broken certificate.

Every input below exits 0 and writes a .pfx. Verified against a 0.6.1-pr build; subject read back with winapp cert info.

--publisher input	exit	resulting subject
CN=	0	CN=""
=Contoso	0	CN="=Contoso"
CN=A,,O=B	0	CN="CN=A,,O=B"
Contoso, Inc	0	CN="Contoso, Inc"
CN=Contoso\Bar	0	CN=Contoso\Bar

Valid input behaves correctly: CN=Contoso Inc, O=Contoso, C=US round-trips as a proper three-component DN.

Two distinct problems:

1. CN= yields an empty common name. A certificate with CN="" can never match any manifest Identity/@Publisher.
2. Unparseable DNs are silently re-wrapped as a literal CN rather than rejected. CN=A,,O=B becomes a single CN whose value is the string CN=A,,O=B. The user asked for a two-component DN and got something entirely different, with no diagnostic.

CN=Contoso\Bar is also worth a look: the packaging schema type ST_Publisher_2010_v2 has no escape sequences, so a publisher containing a backslash cannot match a manifest.

Why this matters: the publisher exists solely so the certificate matches Identity/@Publisher. When it silently doesn't, the failure surfaces much later as an install failure with no obvious link back to cert generation.

Suggested fix: validate --publisher and exit non-zero with a message naming the offending component. If a value cannot be parsed as a DN, say so rather than falling back to treating it as a bare name.

Context: found while wiring the VS Code extension's winapp.certGenerate publisher prompt. We deliberately pass the user's string through unmodified so the CLI owns validation — which is the right layering, but currently means nothing validates it. Related: #839 (same silent-fallback shape on the --manifest path).