ci(windows): add manual Microsoft Store flight submission

[jensenpat]

Dependency

This is a stacked PR built on #5345. The current GitHub diff therefore includes the symbol-packaging prerequisite from that PR. Do not merge this PR before #5345. After #5345 is squash-merged, this branch must be rebased onto the updated main so the diff contains only the manual-flight increment and its non-verbose logging follow-up.

Summary

• add an explicit workflow_dispatch checkbox to build Windows and fully submit the resulting .msixupload to an existing Partner Center developer package flight
• generate a monotonically newer flight-only MSIX version from the source CalVer plus the Windows Installer workflow run number, without creating a public tag or release
• add a separate flight publication job that requires AETHERSDR_STORE_FLIGHT_ID, passes it explicitly as --flightId, retains --uploadTimeout 300, and uses -Commit for full automatic submission
• keep --verbose disabled for production and manual-flight Store submissions so public Actions logs do not expand authentication or upload diagnostics
• document initial Partner Center flight setup and the API-owned submission lifecycle

Production isolation

The existing production path is unchanged: v* tags still stage drafts with --noCommit. The flight job runs only for an explicit manual dispatch in aethersdr/AetherSDR, requires a nonempty flight secret before authentication, and fails rather than falling back to production. FlightId has no environment default in the PowerShell wrapper. The manual path has no schedule and does not create or attach to a GitHub Release. Neither path enables --verbose.

The repository-level Actions secret list does not currently expose AETHERSDR_STORE_FLIGHT_ID; it must be added before the workflow can publish unless an organization secret with that name is already scoped to this repository.

Full-auto behavior

Microsoft documents --flightId as the package-flight target and --noCommit as the option that prevents automatic commit. The pinned CLI source confirms that a publish with a flight ID and without --noCommit calls the flight-specific commit API and polls the resulting status.

• https://learn.microsoft.com/en-us/windows/apps/publish/msstore-dev-cli/commands
• https://learn.microsoft.com/en-us/windows/uwp/monetize/commit-a-flight-submission

Validation

• actionlint .github/workflows/windows-installer.yml
• PowerShell AST parse of packaging/windows/publish-store.ps1 at the original
  flight commit; the security follow-up removes only the --verbose array
  element and its preceding comma
• production argument construction includes --uploadTimeout 300 --noCommit, contains no flight ID, and does not include --verbose
• flight argument construction includes --uploadTimeout 300 --flightId TESTFLIGHT, omits --noCommit, and does not include --verbose
• timeout range check rejects 99 seconds
• flight version check produces 26.9.1.203 for source 26.9.1 and workflow run 203
• python3 tools/check_test_registration.py --strict
• python3 tools/check_engine_boundary.py --strict
• git diff --check

No socket-based tests were run or added. No Microsoft Store submission was triggered.

Generated with OpenAI Codex (Daybreak Blue)

[ten9876]

Scope note first

Stacked draft on #5345, correctly disclosed: the GitHub diff includes the whole symbol-packaging base, so this review covers only the incremental commit d3fd0555 (+168/−3 across the workflow, docs, and publish-store.ps1). Everything else was reviewed on #5345 — including the still-open item there (the docs-vs-create-msix.ps1 duplicate-PDB invocation), which this branch inherits and which the post-merge rebase the body promises will need to pick up.

The increment

The isolation claims all verify in the diff itself: flight publication requires the explicit workflow_dispatch checkbox and github.repository == 'aethersdr/AetherSDR' and a nonempty AETHERSDR_STORE_FLIGHT_ID validated before authentication; a missing flight ID throws rather than falling back to production ("Refusing to fall back" is in the error text); the job holds permissions: contents: read and touches no release; and the production tag path keeps --noCommit untouched. The flight-version scheme is sound — run-number fourth component, 1..65535 guarded, monotonic per workflow — and the doc honestly covers the two sharp edges (the portal-created-first-draft trap, and the requirement that the next production release out-rank 26.9.1.* flight builds). The mocked-invocation validation rows are the right evidence for an untriggerable-from-PR-CI path.

Blockers

None in the increment. The governing constraint is the stacking itself: do not merge before #5345, and the rebase after its squash-merge must resolve #5345's outstanding review items, not just replay d3fd0555.

Nits (non-blocking)

1. -Commit without -FlightId is a one-line-edit away from full production certification (inline). The script gains routine -Commit usage for flights, but nothing refuses the combination of -Commit and no flight — a future workflow edit that drops the -FlightId line (or a copy-paste of the flight invocation into the production step) commits production straight to certification with no second gate. A guard requiring an explicit -CommitProduction (or refusing -Commit when -FlightId is empty) makes the dangerous combination unsayable by accident.
2. --verbose on msstore publish in public Actions logs carries over from #5345 (flagged there) — the flight job doubles the exposure surface.
3. The body notes AETHERSDR_STORE_FLIGHT_ID is not yet in the repository secret list — worth a checklist item on the merge so the first dispatch doesn't fail on configuration.

What was verified vs read

Every isolation claim was checked against the increment's own lines (conditions, permissions, validation ordering, artifact-count check); the Microsoft CLI behavior claims (--flightId + no --noCommit → flight commit API + poll) rest on the linked docs and the body's pinned-source reading, not on execution — this path cannot run from PR CI by design, and its first real execution will be the actual test. No multi-angle automated pass on this PR: 80% of the diff is #5345's content, which already received it; the increment got a focused manual pass instead — stated so the two aren't conflated.

[ten9876]

Nit (non-blocking, defense-in-depth): with flights making -Commit routine, nothing refuses -Commit + empty -FlightId — that combination is full production certification with no second gate, one dropped line away from the flight invocation. Making it unsayable by accident:

Suggested change

	if (-not [string]::IsNullOrWhiteSpace($FlightId)) {
	if (-not [string]::IsNullOrWhiteSpace($FlightId)) {
	$publishArgs += @("--flightId", $FlightId)
	}
	elseif ($Commit -and -not $CommitProduction) {
	throw "-Commit without -FlightId would send the PRODUCTION submission straight to certification. Pass -CommitProduction if that is genuinely intended."
	}

(with a [switch]$CommitProduction param; the current tag path passes neither, so nothing changes for it).

[jensenpat]

Addressed the public-log security nit in 0cbb930: the shared Store publisher no longer passes --verbose, so both production drafts and manual developer-flight submissions use default CLI verbosity. The flight path still passes --uploadTimeout 300, --flightId, and -Commit; production still receives --noCommit. Documentation and the PR validation claims were updated accordingly.