cert generate --manifest silently falls back to the OS user name when publisher extraction fails

Summary

winapp cert generate --manifest <path> silently falls back to the current user name when it cannot extract the publisher from the supplied manifest. It exits 0 and reports success, so callers cannot tell the manifest was ignored.

Repro

Given a well-formed but incomplete manifest (valid XML, correct root namespace, valid Identity/@Publisher, but missing Dependencies/Resources/Applications):

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10">
  <Identity Name="FlowHarnessApp" Publisher="CN=FlowHarnessPublisher, O=Fabrikam Inc, C=US" Version="1.0.0.0" />
  <Properties>
    <DisplayName>Flow Harness</DisplayName>
    <PublisherDisplayName>Fabrikam</PublisherDisplayName>
    <Logo>logo.png</Logo>
  </Properties>
</Package>

winapp cert generate --manifest .\Package.appxmanifest --output .\probe.pfx --if-exists overwrite --json

Actual (exit code 0):

{
  "certificatePath": "C:\\...\\probe.pfx",
  "password": "password",
  "publisher": "chiaramooney",
  "subjectName": "CN=chiaramooney"
}

The Identity/@Publisher in the manifest is ignored and the OS user name is used instead.

Adding the missing Dependencies, Resources, and Applications elements makes the same command extract correctly:

{ "publisher": "CN=FlowHarnessPublisher, O=Fabrikam Inc, C=US", ... }

Why this matters

The whole reason to pass --manifest is to guarantee the certificate's publisher matches Identity/@Publisher — a mismatch makes the resulting package fail to install. Falling back to the user name produces a certificate that can never match, and reports success while doing so. Partially-complete manifests are common mid-development, which is exactly when a dev certificate gets generated.

Verified against bundled CLI 0.6.0 and dev build 0.6.1-pr.

Expected

When --manifest is passed explicitly and the publisher cannot be extracted, fail with a non-zero exit and a clear error (or at minimum emit a warning) rather than silently substituting the user name. The user-name fallback is reasonable when no publisher source was given at all; it is not reasonable when the caller named a manifest.

Context

Filed from the WinApp VS Code extension (microsoft/WinAppVSCE), which passes --manifest for exactly this guarantee. We have added a client-side check that re-reads Identity/@Publisher and warns the user when the returned publisher disagrees, but that is a workaround for a CLI behaviour that should be surfaced by the CLI itself.

Start by reproducing winapp cert generate --manifest ... --json with the incomplete manifest shown, then trace the manifest publisher extraction and fallback path. Done means an explicitly supplied manifest that cannot yield a publisher produces a non-zero exit and clear error or warning, while the user-name fallback remains available when no publisher source is supplied.