Automate Microsoft Store updates from tagged releases

## Problem

After the first Store release, package updates would still require manual Partner Center work. The release workflow needs a protected path from a validated tagged build to the live Store product without exposing credentials to pull requests or development builds.

## Proposed change

Associate a Microsoft Entra tenant with Partner Center, register a dedicated automation application, and grant only the Partner Center access required by the currently documented Store submission flow. Store its tenant ID, seller ID, client ID, and client secret in a protected GitHub environment. On an approved stable version tag, publish the exact validated `.msixupload` with a pinned Microsoft Store Developer CLI setup and record Partner Center's submission response; certification and publication continue asynchronously in Partner Center.

## Acceptance Criteria

- [ ] AC1: A dedicated Microsoft Entra application is associated with Partner Center using the documented Manager role, or a narrower officially supported role proven sufficient, and its credential owner, expiry, and rotation procedure are recorded.
- [ ] AC2: Tenant ID, seller ID, client ID, and client secret are stored only as protected GitHub environment secrets; the Store product ID is stored as a non-secret configuration value.
- [ ] AC3: Pull requests, forks, ordinary branch pushes, and development-release jobs cannot access the Store environment or invoke a production submission.
- [ ] AC4: An approved stable tag downloads the exact validated `.msixupload` for that version, verifies the contained `.msix` checksum, and publishes it with a pinned Microsoft Store app-publisher action or Store Developer CLI version using only `contents: read` repository permission.
- [ ] AC5: The submission job exposes the product, package version, and Partner Center response in the workflow summary without exposing credentials, and fails closed when authentication, upload, validation, or commit fails.
- [ ] AC6: The job records the submission identifier and initial Partner Center status, while operator guidance explains how to inspect later certification, rejection, publishing, and **In the Store** states without holding one GitHub-hosted job open for multiple days.
- [ ] AC7: Re-running a release cannot submit a different artifact under the same package version or silently regress the Store version.
- [ ] AC8: The automation remains explicitly limited to the free product supported by Microsoft's current update tooling and fails with a clear operator error when a CLI or Partner Center prerequisite is not met.

## Dependencies

Blocked by **Publish the first Microsoft Store release**.

## Implementation classification

- **Estimated size:** M
- **Orchestration risk:** High
- **Reason:** This adds a credentialed external release integration with trust-boundary, idempotency, asynchronous-state, and versioning requirements.

First confirm that “Publish the first Microsoft Store release” is complete, then review the existing release workflow and Microsoft's documented Partner Center submission flow. Map the protected GitHub environment, stable-tag entry point, validated .msixupload, and asynchronous submission status to AC1–AC8. Done means the acceptance criteria are verified without exposing credentials or allowing an unapproved artifact to be submitted.

索引モデルが issue の本文から書いたものです。