Establish supported host and capability access for AppInstallManager cmdlets

Parent: #232

Dependencies and access restriction

The technical development gate is partially satisfied by observed activation, property reads and caller-scoped search. On 2026-09-14 the maintainer authorized scoped development of #234 and the initial caller-scoped work in #236, #238 and #244, subject to their code dependencies.

This issue remains open for authoritative supported-distribution and broader API/user-scope clarification. It no longer blocks the approved subset, but remains a gate for unverified operations. A zero-item search does not validate actual download/install, queued-item transitions or another user's access.

Evidence: host/getter matrix and authorized caller-scoped search. This is empirical runtime evidence, not an official third-party support guarantee.

Microsoft documents AppInstallManager access as protected by a private capability restricted to Microsoft-developed apps. Do not bypass that restriction or treat runFullTrust/admin access alone as sufficient.

Goal

Resolve the documented support contract and per-API access matrix before promising generally supported distribution or expanding beyond the maintainer-approved development subset.

Acceptance criteria

• Confirm the documented private-capability restriction to Microsoft-developed apps; distinguish it from runFullTrust, administrator privileges, package identity and mere successful type activation.
• Produce a supported-host matrix for the intended PowerShell distribution: packaged/unpackaged context, identity/capability requirements, minimum Windows/SDK contracts, user/session scope, and per-member access restrictions.
• Use documented, authorized, read-only evidence where possible. A constructor or metadata probe alone is not proof that installation, entitlements or user-scoped operations are authorized.
• Record each relevant method family as supported, access-denied, unavailable, retired or unverified, with sources and reproducible leak-safe evidence. Do not treat denied access as an empty queue or a successful no-op.
• Establish the C# WinRT projection/hosting approach and runtime limitations without prescribing an owning module prematurely.
• If a supported public distribution cannot meet the access requirements, document that limitation and keep unverified operations gated. The approved foundation/caller-scoped subset may be developed without claiming official support. Do not impersonate a privileged package, spoof identity, change policy or bypass access checks.
• Retired StartAppInstallAsync overloads are explicitly excluded from new default behavior; record documented alternatives.

This child is an investigation/contract gate, not authorization to perform live installation, entitlement or configuration mutations.

Shared delivery requirements

Follow the parent epic's compiled-C# contract, user-scope and capability/version gates. Include deterministic Pester 6.2+ coverage, comment-based help, public documentation and unreleased notes in the same implementation PR. Use fail-closed fake adapters for side effects; no real installs, entitlement grants or settings changes in CI. Preserve original errors and distinguish unavailable, unknown, requested and completed outcomes.

Documented API references

• https://learn.microsoft.com/uwp/api/windows.applicationmodel.store.preview.installcontrol.appinstallmanager

Start with the linked Microsoft AppInstallManager API reference, then review the host/getter matrix and authorized caller-scoped evidence in the issue comments. Produce the supported-host and per-member access matrix with documented sources, reproducible leak-safe evidence, hosting limitations, and gated unverified operations; include the required Pester 6.2+ coverage, help, documentation, and unreleased notes.