[rodchristiansen]

Closes #32

Policy line

• Policy-set settings no longer carry a per-field "Managed by policy" caption or lock. Their controls stay disabled in the default gray, and an empty caption collapses.
• One line at the top of the Prefs tab reads "Settings shown in gray have been configured by a policy." It shows only when policy sets at least one value (HasPolicySettings).

Services card

• A read-only accordion card at the bottom lists the one thing the installer creates, the StartSet service. The installer creates no scheduled tasks.
• Each row is an Expander, collapsed by default. It shows the friendly name, one summary line (Service · Automatic · LocalSystem), and a state dot and word on the right. The dot colours come from theme brushes only: success for Running, attention for Ready, neutral otherwise.
• The Expander's header is a full-width ToggleButton in the WinUI template, so a click anywhere on the row, or Space or Enter, toggles it.
• Expanded, a row lists Name, Start type, Status, Account, Path and arguments, Triggers and, once stopped, Last result. These are the labels ReportMate's Windows System module uses. A value that cannot be read is left out.
• Data comes from WMI Win32_Service, read off the UI thread with no elevation and no new package. A failed query shows "Unknown".
• The query and wording live in StartSet.Infrastructure.Gui.InstalledServices.
• No times appear on this card: a service has no last run, next run or trigger time, so there is nothing to format by culture.

No Unlock mode

• The read-only banner, the Unlock button and the elevated relaunch of the whole app are gone. Whether a setting can be edited depends on policy alone (PrefsElevation.CanEdit(isPolicyManaged)).
• Edits are held as pending. Save and Discard appear only when there are unsaved changes, where the "Running as administrator" row used to be.
• Save writes machine settings directly when the app is already elevated. Otherwise it opens a named pipe with a random name and starts the app's own executable with runas and --apply-settings <pipe name>.
• The pipe is created with FirstPipeInstance, so nothing can hold the name first, and its ACL admits only the current user, Administrators and SYSTEM. The JSON is written when the elevated run connects, then the pipe closes. Nothing touches disk, and this also works when a different administrator approves UAC.
• Save stops waiting after 60 seconds if nothing connects, or as soon as the writer exits without connecting.
• A new Program.Main, which replaces the XAML-generated one, handles --apply-settings before WinUI starts, so that run creates no window. It reads policy again, skips every setting policy sets (and policy-only ones), checks each value with the same rules the tab uses (SettingsPayload.Normalize), writes the rest and exits 0 or non-zero.
• A declined UAC prompt keeps the edits pending and shows "Not saved: administrator approval was declined." Any other failure shows "Not saved: ". On success the tab reloads settings and sources from the registry.
• The README and the app manifest comment no longer describe Unlock.

Tests

• dotnet build and dotnet test on StartSet.sln: 429 passed.
• The App project builds for win-x64.
• New tests cover the services wording, summary and row order, managed versus unmanaged editability, the elevated apply start info, JSON validation, a headless apply over a real pipe that skips policy-set keys, the pipe ACL, the connect timeout, and refusal of a second pipe with the same name.

Risk: medium