test: fix UI test app-exe resolution and build the app in CI before UI tests

[laurentiu021]

Summary

Fixes the UI automation test suite, which has been failing 100% on every run (including
main) — silently, because the job is non-blocking (continue-on-error: true). The job
reported "success" while every test actually errored at fixture setup.

Root cause

AppFixture.FindExecutable() looked for SysManager.exe only under
SysManager/bin/**Debug**/net*-windows, but CI builds the app in Release — and the
UI-tests job never built the app at all. So the fixture threw
FileNotFoundException: Expected SysManager.exe under ...\bin\Debug\net*-windows and all
~20 UI tests failed before launching anything.

Fix

• AppFixture.cs — search both Release and Debug output folders (whichever the
  app was actually built in) instead of hardcoding Debug. Error message now lists both
  searched paths.
• ci.yml — add a step to build SysManager.csproj (Release) in the UI-tests job
  before running the tests, so the exe the fixture launches actually exists.

Verification

• UITests project builds 0 warnings / 0 errors.
• Verified the path math: repoRoot (the solution dir) + SysManager/bin/Release/net10.0-windows/SysManager.exe is exactly where the Release build places the exe (confirmed on disk).
• Cannot run dotnet test locally (environment policy), but the failure was a missing-file
  at fixture init, which both changes directly resolve.

Note: this exposes the deeper issue flagged in the audit (ci-gate-001) — UI tests are
non-blocking, so this rot went unnoticed. That gate change is tracked separately; this PR
makes the tests actually pass first.

test: / ci: — no release.

[laurentiu021]

Closing without merging. This correctly fixes the exe-resolution half (the app now launches in CI — verified: the run took 4m53s vs the prior instant fail), but it surfaced a deeper problem: 58/59 UI tests then fail with 'Nav item not found'. The app DOES set AutomationProperties.AutomationId on nav items (MainWindow.xaml:187), so the cause is almost certainly that collapsed sidebar groups don't realize their children in the automation tree until expanded (WPF virtualization), plus possible timing. Repairing the UI suite is a focused task on its own; merging this alone would just make every CI run 5 minutes slower while the job stays red-behind-the-mask. Keeping the AppFixture Release/Debug fix on the branch as the foundation for that work.

[laurentiu021]

Closing again after a second attempt. Progress confirmed: the app now launches in CI (exe-resolution fix works — run took 5m45s of real UI automation), stale nav-ids/button-labels corrected. BUT the core blocker remains: even with ExpandAllNavGroups (querying ControlType.Group + ExpandCollapse pattern) the child nav items still aren't found ('nav-X not found'). The WPF sidebar Expander apparently doesn't expose children via the Group/ExpandCollapse automation pattern the way assumed, OR children aren't realized synchronously. Reviving this suite needs interactive FlaUI debugging (inspect the actual automation tree to see how the Expander + ItemsControl expose nav Borders) — which can't be iterated here since dotnet test can't run locally (firewall policy). Deferring as a focused task. All fixes preserved on branch test/ui-test-exe-resolution: AppFixture exe-resolution (Release+Debug), ci.yml app-build step, ExpandAllNavGroups scaffold, and the corrected nav-ids/labels (nav-network→nav-ping, List installed drivers→List drivers, etc.). The next attempt should start by dumping MainWindow.FindAllDescendants() names/controltypes/automationids to see the real tree.