[Feature]: Add batched in-process UI automation for PowerShell

[nmetulev]

Is your feature request related to a problem? Please describe.

Parent: #798

The reporter's PowerShell 7 automation suite performs hundreds of UI primitives. Running each search, property read, and action as a separate winapp ui ... process adds process startup, target connection, and selector traversal to every operation, turning large suites into minutes of overhead.

The reporter confirmed that language neutrality is not required. Their suite can consume an in-process .NET package and prefers that approach.

Redundant element resolution inside a single existing command is tracked separately by #840. This issue covers batching multiple operations in one long-lived process and retaining elements between those operations.

Describe the solution you'd like

Provide a PowerShell-friendly in-process batching/session experience based on Microsoft.Windows.SDK.BuildTools.WinApp.UIAutomation:

1. Connect to the target window once.
2. Search once and retain a live element or opaque session-local handle.
3. Perform multiple property reads and actions without restarting the CLI or re-walking the tree for every operation.
4. Define explicit lifetime, disposal, stale-element, target-restart, and provider-error behavior.
5. Make package consumption straightforward from PowerShell without requiring users to manually locate and load a chain of Microsoft.Extensions assemblies or build a project.
6. Keep existing CLI commands and serializable selectors as the one-shot public model.

For example, the intended usage should be conceptually similar to:

$session = Connect-WinAppUi -App MyApp
$send = $session.Find -AutomationId AfterWebViewSend
$send.GetProperty('Name')
$send.GetProperty('IsEnabled')
$send.Invoke()
$session.Dispose()

The exact API remains to be designed, but operations should execute against the retained live element rather than converting it to a DTO and searching again.

Additional context

Measured evidence:

• The reporter's 130-element recursive tree walk took approximately 309 ms, or 254 ms with CacheRequest.
• A direct property read from an already-retained live AutomationElement averaged 0.064 ms in an independent fixture.
• The approximate 10 ms target therefore applies to operations on an already-resolved element, not complete tree discovery.
• PowerShell 7.6.6 on .NET 10.0.12 can load the current net10.0-windows assembly, but full use currently requires manually loading several Microsoft.Extensions assemblies and configuring DI.

Benchmark discovery separately from retained-element operations. A language-neutral JSON-lines protocol or named-pipe broker is outside the initial requirement unless later consumers demonstrate a need for it.

[nmetulev]

The reporter's response and an independent PowerShell experiment significantly narrow this investigation.

Host requirement

The reporter's suite uses PowerShell 7 and already consumes .NET UI Automation in-process. A language-neutral persistent CLI protocol is not required; an in-process WinApp UI Automation package is preferred.

PowerShell 7.6.6 running on .NET 10.0.12 successfully loaded the current net10.0-windows UI Automation assembly, so the current target framework is viable in that environment.

Current package ergonomics

The package is not yet a simple one-file PowerShell experience. A clean PowerShell process does not have ServiceCollection or the Microsoft.Extensions implementation assemblies required by the documented DI construction path. Full use succeeded only after manually loading:

Microsoft.Extensions.Primitives.dll
Microsoft.Extensions.DependencyInjection.Abstractions.dll
Microsoft.Extensions.Logging.Abstractions.dll
Microsoft.Extensions.Options.dll
Microsoft.Extensions.DependencyInjection.dll
Microsoft.Extensions.Logging.dll
Microsoft.Windows.SDK.BuildTools.WinApp.UIAutomation.dll

This suggests that a PowerShell module, bundled dependency layout, or public no-DI facade/factory is needed to meet the requested consumption experience.

Live-element measurement

On a 128-element WinUI/WebView2 fixture, repeated property-style operations measured:

GetPropertiesAsync on a previously returned UiElement DTO: 83.6 ms average
Direct Current.Name on a retained AutomationElement:        0.064 ms average

The current UiElement is a serializable DTO. GetPropertiesAsync resolves it back to a live UIA element by walking the tree again, which dominates the operation. Retaining the live AutomationElement removes that repeated discovery cost and supports the reporter's approximate 10 ms goal for operations on an already-resolved element.

The 10 ms target should not be interpreted as a target for complete tree discovery. The reporter measured a 130-element recursive walk at 309 ms, or 254 ms with CacheRequest; their result also shows that traversal round trips dominate property caching.

Proposed scope adjustment

This issue should now primarily investigate:

1. A PowerShell-friendly in-process facade or module with straightforward dependency loading.
2. Live-element lifetime, stale-element errors, and cleanup semantics.
3. Removing redundant element resolution from existing one-shot operations where possible.
4. End-to-end latency measurements for discovery separately from operations on retained elements.

A persistent language-neutral CLI/session or broker can remain optional future scope rather than a prerequisite for this request.