fix: say that Scheduled Maintenance keeps one schedule, before Save replaces it

[laurentiu021]

Problem

Scheduled Maintenance registers a single Windows task at a fixed name, so Save does not add a second schedule — it overwrites the first. Nothing said so.

• The header mentioned "one Windows scheduled task", which reads as an implementation detail rather than a limit that affects you.
• The Configure card offered an action and a time as though each Save were a new entry.
• The confirmation dialog said "This creates a Windows scheduled task" even when one already existed. So the dialog whose entire purpose is to stop an unwanted change actively concealed which change it was.

Someone who wanted a weekly cleanup and a monthly standby purge would have set the second, silently lost the first, and then seen the tab report the survivor as though nothing had gone.

What changed

Three statements of the same fact, at the three moments it matters.

The header now says SysManager keeps one schedule at a time and that saving a new one replaces the previous one.

A line beside the Save button says the rule, and changes to "saving this replaces the one above" as soon as a schedule exists — so it reads as a warning only when there is something to lose, and as reassurance otherwise.

The confirmation asks a different question in each case. Replacing says so in those words, and names the time the old schedule was next due. That is the only detail available: the status read-back reports state and times, not which action or trigger Windows is holding. It is enough to tell the user which schedule they are about to lose, and it comes from the same read the card above displays, so the dialog and the card cannot disagree. The dialog title changes too — "Replace Schedule — Confirm" rather than "Schedule Maintenance — Confirm".

What deliberately did not change

No new CLI verbs and no new actions. #1509 originally proposed adding a scheduled health check and a browser-cache clean. Supporting several schedules — which more actions would create an expectation of — was considered and turned down, and the reason is now written into the code and the CHANGELOG rather than living in an issue: the design rests on touching exactly one task by name, and that is precisely what keeps the feature from needing administrator rights and what makes it incapable of disturbing anything else Windows has scheduled. The headless attack surface is unchanged.

Verification

5 new tests, asserted through DialogAnswer rather than the file's older hand-rolled DialogService swap — for this gate the wording is the behaviour, and the older helper cannot read it. A second NewScheduledVmAsync helper mirrors MaintenanceSchedulerServiceTests.StatusRow so the "a task already exists" path is reachable at all; it had no test before.

Red ritual — four mutations, each red for the right reason, green after restore, every file restored from saved bytes and rebuilt before running:

Mutation	Red
the pre-fix single confirmation text	2 — the replace wording, and the create wording too, since even the create case now states the rule
the note stops depending on whether a schedule exists	1
the replace text drops the next run	1
the dialog title stops distinguishing replace from create	1

The 2 in the first row is worth stating: I predicted 3, and the fourth new test — "declining a replacement leaves the task alone" — passes either way, because No meant No before this change too. It is a regression guard on a path that had no test, not a proof of this one.

• Unit suite: 5798 passed, 0 failed (5793 before).
• All four projects: dotnet build -c Release, 0 errors, 0 warnings.
• dotnet format --verify-no-changes: clean.
• Leak scan: 43 patterns over 6 changed files, and the only match is the long-standing false positive from a Windows privacy-toggle name that predates this branch and is not in the diff.
• Grepped for the old copy across .cs, .xaml and .md: no test or doc quoted it, and AllTabsSmokeUiTests checks only the unchanged Display header.
• README's Scheduled Maintenance section gained the one-schedule bullet, in the same PR.

Closes #1509