Surface hidden failures: out-of-order phonemes and unhandled exceptions

[KakaruHayate]

Two small, unrelated changes that make hidden failures visible. Kept as two commits so they can be split into two PRs if you prefer.

1. ustx: log when a phonemizer returns out-of-order phonemes

UPart.Update silently repairs out-of-order phoneme positions:

// Safety treatment after phonemizer output and phoneme overrides.
for (int i = phonemes.Count - 2; i >= 0; --i) {
    phonemes[i].position = Math.Min(phonemes[i].position, phonemes[i + 1].position - 10);
}

That repair covers two very different causes:

• a user dragging a phoneme offset past its neighbour — legitimate, and the reason the code exists;
• a phonemizer returning positions out of order — a bug.

Because the repair is silent, the second case is invisible: the part just renders slightly odd. No test can see it either, because the test harness calls Phonemizer.Process directly and never reaches this code path.

The patch adds a read-only ordering check on rawPosition, which holds the phonemizer output before user overrides are applied, so only the phonemizer case is reported. One warning per part; the repair itself is unchanged.

I measured the built-in phonemizers through the test harness and found no violations across 598 phonemes / 318 note groups, so this should normally stay quiet — silence is the useful signal here.

2. app: also handle unobserved task and unhandled UI exceptions

Program.InitLogging registers AppDomain.CurrentDomain.UnhandledException, which can log an exception but cannot keep the process alive. Nothing is registered for the two cases users actually hit:

• TaskScheduler.UnobservedTaskException — a faulted Task that nobody awaited is dropped until finalization, and then ignored.
• Dispatcher.UIThread.UnhandledException — this code base has 47 async void methods, 31 of them menu/button handlers. An exception escaping one reaches the dispatcher, nothing marks it handled, and the process exits: the window simply disappears.

Both hooks are registered in OnFrameworkInitializationCompleted, where Avalonia is up and we are on the UI thread. Exceptions are logged and surfaced through the existing ErrorMessageNotification path.

This does not fix any root cause. A null reference still has to be fixed where it is thrown (as #2390 did). It only turns "process gone" into "error reported", so an unforeseen exception costs the user a dialog instead of their session.

Verification

dotnet build with both patches applied	0 errors, 0 warnings
dotnet test full suite	238 passed, 0 failed — identical to the baseline before the change

Neither change alters behaviour for the existing suite; the App-level one only changes behaviour in cases that would otherwise terminate the process.

Happy to adjust or drop either part — for example lowering the new log to Debug, or splitting this into two PRs.