Add protected Windows MXC E2E and activation gate

Part of #8178.

This task owns the final qualification-backed activation decision for the accepted native Windows OpenClaw profile. Passing tests alone do not establish product approval.

## Outcome

The exact accepted Windows/OpenShell/MXC/OpenClaw profile passes protected clean-host E2E and becomes selectable only through an accepted activation registration and product decision.

## Delivery state

Protected qualification and activation gate.

## Dependencies

- Blocked by #10586, #10587, and #10588.
- Requires maintainers to accept the product scope, compatibility matrix, privilege model, support lifecycle, and technical-preview boundary in #8178.

## Deliverables

- Add the protected Windows qualification matrix for install or accepted attachment, preflight, onboarding, create, readiness, authenticated chat, policy, managed inference, lifecycle, recovery, cleanup, repair, and uninstall where accepted.
- Bind authority to the exact candidate commit, base commit, workflow run, job, attempt, artifact, host, OpenShell, MXC/`wxc-exec.exe`, Node.js, and OpenClaw identities.
- Add the activation declaration only when every required surface and qualification field truthfully matches the accepted Windows profile.
- Keep every unsupported host, backend, capability, and agent profile unselectable.

## Acceptance evidence

- Allowed: the exact protected qualification authority activates only the accepted provider profile.
- Denied: local logs, prototype evidence, stale commits, different packages, unsupported hosts, partial matrices, and self-asserted receipts cannot activate the provider.
- Ambiguous: failed, cancelled, incomplete, or mismatched protected runs leave MXC inactive.
- Failure or recovery: clean-host E2E proves bounded rollback, exact cleanup, repair, and uninstall behavior for the accepted scope.

## Security and authority boundaries

- Protected workflow identity, artifact provenance, host identity, provider authority, policy, credentials, and cleanup evidence must remain independently verifiable.
- Product approval remains separate from technical qualification.
- Activation must use the shared runtime-provider activation seam and must not modify the established provider registry directly.

## Test plan

- Focused activation and negative-authority tests.
- Complete protected Windows E2E against the exact candidate commit.
- Regression coverage proving Docker and every other supported provider remain unchanged.

## Deferred scope

- Hermes until `isolation_session` is accepted and qualified.
- Unaccepted Windows builds, architectures, update channels, GPU modes, inference providers, and lifecycle capabilities.

## Stop conditions

- Stop without explicit product approval and complete protected evidence.
- Stop if activation requires emulating Docker, weakening shared contracts, or adding a central MXC switch.

## Completion evidence

- Link the activation PR, exact verified commit, protected run and artifact identities, accepted product decision, support matrix, and final documentation evidence. One same-repository PR should close this issue.