[Bug]: ui get-value returns a text box's label when its value is empty

Describe the bug

winapp ui get-value can return an empty text box's accessibility label instead of its actual empty value. For example, an empty title field is reported as containing Intention title, required.

This is a shared UI Automation value-reading bug, not a sandbox-specific bug. It was originally observed in Windows Sandbox, but independently reproduced against the shared implementation using an isolated test with simulated UI Automation providers. A paired live local/sandbox reproduction has not been performed.

Agents and tests cannot reliably determine whether a field is empty. wait-for --value "" also uses the same value-reading method, so it can fail to match an existing empty field.

To Reproduce

Independent, isolated reproduction (source revision 2e307c7e8e648a1906205241148de20bcf12f7ab):

dotnet run --project src\winapp-CLI\WinApp.UIAutomation.Tests\WinApp.UIAutomation.Tests.csproj -c Debug -- --filter "FullyQualifiedName~FaultInjectedComProxies_CoverEmptyTextAndValueFallthrough"

The test supplies successful empty TextPattern and ValuePattern reads and an accessibility name of Fallback Name. The actual shared GetTextAsync implementation returns Fallback Name, not an empty string. The test passed on September 18, 2026 because it currently asserts the incorrect fallback behavior; that pass confirms the defect rather than validating the desired behavior.

Relevant source at the tested revision:

• GetTextAsync: skips successful empty TextPattern and ValuePattern reads before falling back to Name.
• Existing isolated test: expects Fallback Name for an empty control.

Originally reported UI example (not independently rerun against the live app): with an empty labeled text box selected by TaskTitleInput, get-property ... -p Value --json returned {"properties":{"Value":""}}, while get-value ... --json returned {"text":"Intention title, required"}. The report used CLI 0.6.3-prerelease.52 in an ARM64 sandbox.

Expected behavior

A successfully read empty text/value is valid and should be returned as "". An accessibility label must not replace it simply because it is empty.

Recommended fix:

• Preserve successful empty reads from supported text/value patterns; retain the existing intentional pattern precedence.
• Fall back to the accessibility name only when the appropriate text/value source is unavailable, not when it returns an empty string.
• Correct the existing test and add regression coverage for empty, whitespace-only, and nonempty values, plus fallback when patterns are unsupported.
• Verify that get-value and wait-for --value "" agree for a fresh empty field and a field cleared after editing.

Do not remove the app's accessibility label or weaken assertions as a workaround.

Screenshots

N/A. The independent reproduction uses simulated UI Automation providers and requires no app window.

OS Version and details

Independent isolated reproduction: Windows ARM64, .NET 10.0.12, MSTest 4.1.0, repository revision 2e307c7e8e648a1906205241148de20bcf12f7ab.

Original live report: CLI 0.6.3-prerelease.52, native ARM64 host and Windows Sandbox. The bug was independently confirmed in shared code; live host-versus-sandbox comparison remains untested.

Start in src/winapp-CLI/WinApp.UIAutomation/Services/UiAutomationService.cs at GetTextAsync, then read the existing test in src/winapp-CLI/WinApp.UIAutomation.Tests/RealUiAutomationTests.Coverage.cs. Run the provided filtered test and update coverage for empty, whitespace-only, nonempty, and unsupported-pattern cases. Done means successful empty reads remain empty, fallback still works when patterns are unavailable, and get-value agrees with wait-for --value "".