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

### 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:

```powershell
$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.

Start by reviewing the existing `winapp ui` commands and the `Microsoft.Windows.SDK.BuildTools.WinApp.UIAutomation` package, including how PowerShell currently loads its dependencies. Define the session, retained-element, disposal, stale-element, target-restart, and provider-error behavior before implementing the API. Done means PowerShell can connect once, reuse resolved elements for multiple operations, and consume the package without manual assembly loading while existing CLI commands remain unchanged.

Written by the indexing model from the issue text.