Remove stale Store packages during publish

[michaeljolley]

Problem

The Microsoft Store still shows the old 1.1.0.0 loose .msix installers alongside the current .msixbundle. Partner Center builds every new submission as a copy of the last published submission, so those stale packages keep getting re-cloned. msstore publish only removes an inherited package when a newly submitted file has the same extension — our new file is a .msixbundle, so the 1.1.0.0 .msix files are never matched and linger indefinitely.

Fix

Split the Store submission into publish-then-clean, done in a single submission (one certification pass):

1. msstore publish <bundle> --noCommit — creates/uploads the draft but does not commit.
2. A new step uses the Store submission REST API to mark every package whose version differs from the release version as PendingDelete, PUTs the edited draft, then commits and polls for acceptance.

Why the REST API instead of msstore submission update

msstore submission update passes the whole submission JSON as a command-line argument (Windows caps args at ~32 KB) and deletes the draft when pricing.priceId == "Base". The REST API avoids both hazards and lets us surgically flip fileStatus.

Notes

• This is a one-time transition artifact (loose .msix → bundle). Going forward, bundle-over-bundle releases are self-cleaning; the version-based filter simply becomes a no-op.
• Fails safe: if anything in the cleanup errors, the submission is not committed, so a stale package set is never re-published.

Requires no new secrets — reuses PARTNER_CENTER_TENANT_ID, PARTNER_CENTER_CLIENT_ID, PARTNER_CENTER_CLIENT_SECRET, and STORE_PRODUCT_ID.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com