ci: automate Microsoft Store AppX publishing

[khaira777]

Summary

• Build the Microsoft Store AppX package alongside tagged Windows releases.
• Validate the AppX identity, publisher, and version before handing it to the publish job.
• Transfer the package through an immutable GitHub Actions artifact.
• Publish through Microsoft's Store CLI behind the protected production-release environment.
• Keep the Store jobs tag-push-only so workflow_dispatch cannot submit arbitrary branch code.
• Pin the Microsoft Store CLI to v0.3.9 and pin the setup action to its commit SHA.
• Extend release configuration tests to cover the Store path and preserve the existing NSIS path.

Required repository setup before enabling a Store release

1. Create the production-release GitHub Environment with required reviewers and self-approval disabled.
2. Add these environment secrets:
   • AZURE_AD_TENANT_ID
   • AZURE_AD_APPLICATION_CLIENT_ID
   • AZURE_AD_APPLICATION_SECRET
   • SELLER_ID
3. Register the Entra application in Partner Center with the role required by Microsoft's Store CLI documentation.
4. Confirm that product ID 9n1md6585p4q is the intended Flo Cafe listing and that its package identity/publisher match package.json.
5. Test the first submission using a Store flight or draft workflow before allowing a production submission.

Verification

• PATH=/opt/homebrew/bin:$PATH npm run test:release-config
• PATH=/opt/homebrew/bin:$PATH npm run lint (existing warnings, no errors)
• PATH=/opt/homebrew/bin:$PATH npm run build
• PATH=/opt/homebrew/bin:$PATH npm test
• git diff --check
• Ruby YAML parse of .github/workflows/release.yml

Windows AppX generation and Partner Center submission require GitHub's Windows runner and repository credentials, so they cannot be executed locally.

[khaira777]

@itsbkm — Microsoft Store setup requested before merging PR #260

Before merging

1. In repository Settings → Environments, create production-release.

   • Add required maintainer reviewers.
   • Disable self-approval where available.
   • Restrict deployments to the repository’s protected X.Y.Z release tags.
   • This environment will also be used by the later macOS production-submission PR.

2. In Partner Center, confirm the Flo Cafe listing and package identity:

   • Product ID: 9n1md6585p4q
   • Identity: CodifyAppsPrivateLimited.FloCafe
   • Publisher: CN=34AFD24D-EC88-44B8-B309-08BB8A6BB5F7

3. Register/authorize the Entra application in Partner Center with the role required by Microsoft’s Store CLI documentation. Store these environment secrets in production-release:

   • AZURE_AD_TENANT_ID
   • AZURE_AD_APPLICATION_CLIENT_ID
   • AZURE_AD_APPLICATION_SECRET
   • SELLER_ID

4. For the first validation run, optionally add environment variables (not secrets):

   • MSSTORE_FLIGHT_ID=<Partner Center flight ID>
   • MSSTORE_NO_COMMIT=true

   The workflow passes these to msstore publish, allowing a flight/draft validation instead of committing the first package to production. Remove them after the validation is accepted.

How the workflow works after merge

• A pushed strict X.Y.Z tag runs the Windows Store build job.
• That job has no Store credentials. It builds release/*.appx, validates identity/publisher/version, and uploads one immutable artifact.
• The publish job downloads only that artifact, configures the pinned Microsoft Store CLI (v0.3.9), and waits for the protected production-release approval.
• workflow_dispatch remains available for the existing release workflow, but both Store jobs intentionally skip it; arbitrary branch code cannot be submitted to the Store.
• The existing NSIS/GitHub Releases path remains separate and unchanged.

After merging

1. Merge the PR.
2. Prepare the normal release version and changelog.
3. Push the matching X.Y.Z tag.
4. Approve publish-windows-store only after checking the tag and build summary.
5. Confirm Partner Center submission/certification and test an existing Store installation updating.
6. If the first run used a flight/draft, remove the temporary environment variables before the first production submission.

Anyone with repository Write access may be able to enqueue a workflow, but the Store submission cannot complete without the protected environment approval. Tag rulesets and environment reviewers are the actual maintainer gate.

Microsoft reference: https://learn.microsoft.com/en-us/windows/apps/publish/msstore-dev-cli/github-actions

[khaira777]

@itsbkm Governance prerequisite: issue #204 now contains the complete main/tag ruleset checklist and the remaining follow-up release-gating work. Current repository inspection found no active rulesets and no branch protection record for main: #204 (comment)