A failed preference restore never reaches the tray status line when the tool has an OnStart: a successful OnStart clears the seeded error #12

What's wrong

TrayAppBuilder.RunTray seeds the preference-restore failure into the menu with menu.SeedError(restoreError), so the tray's status line can show it. TrayApplication.OnFrameworkInitializationCompleted then calls menu.Run(app.OnStart). On success, TrayMenu.Run sets LastError = null. This happens before the menu is ever painted, so the seeded restore error is wiped.

Failure scenario

1. A remembered toggle's setter refuses during restore (e.g. "no inhibitor"). restoreError = "ds failed: no inhibitor" is seeded.
2. The tool has an OnStart (the repo's own demo does), and it succeeds.
3. LastError becomes null, and RefreshMenu shows the normal status getter's text.

The user sees a healthy status line, although their remembered setting was not applied. The message only ever reaches stderr, which a tray app usually has no terminal for. The #6 work was meant to surface exactly this kind of failure in the tray, and it only works for tools without OnStart.

This was reproduced under xvfb with a ConfigHome preferences file {"Toggles":{"running":true}} and a throwing setter:

• With no OnStart, the status getter is never consulted and the error header stays.
• With an OnStart, the status getter runs straight after it and the error is gone.

Suggested fix

In TrayApplication, keep the seeded error when OnStart succeeds:

string? seeded = menu.LastError;
if (menu.Run(app.OnStart) && seeded is not null)
{
	menu.SeedError(seeded);
}

Alternatively, seed the restore error after OnStart has run. If OnStart itself fails, its own error should win, as it does today.

Acceptance criteria

• A test with a failing restore and a succeeding OnStart shows the restore error in the status line.
• The existing no-OnStart test still passes.