Fix: guard Win2D draw callbacks so a render exception can't crash the app

[andrewtheart]

What

Guards the four Win2D Canvas_*_Draw callbacks (Canvas_Text_Draw, Canvas_Selection_Draw, Canvas_Cursor_Draw, Canvas_LineNumber_Draw) with try/catch so a transient rendering exception can't crash the host app.

Why

A CanvasControl draw callback runs inside WinUI's composition/render pipeline. If it throws, WinUI re-raises the exception as a stowed exception (0xc000027b) that fail-fasts the entire process and bypasses the managed UnhandledException handler — so the app has no way to catch or recover.

In practice this can happen on very large or rapidly-changing content, where the rebuilt CanvasTextLayout and a computed selection/geometry index momentarily disagree and a call like CanvasTextLayout.GetCharacterRegions throws E_INVALIDARG. The result is a hard crash of the whole application from inside the control.

Change

Wrap each draw handler's rendering call in try/catch and log via Debug.WriteLine. initializationManager.CanvasDrawed(n) is intentionally left outside the try so initialization tracking still completes. The worst case becomes a single skipped frame (the canvas redraws on the next invalidation) instead of a process crash.

No behavior change on the success path; no new dependencies.

Testing

• Builds clean (TextControlBox.csproj, Release/x64).
• A deliberately throwing render (huge single-line content + selection churn) no longer crashes the host; it logs and redraws on the next frame.

Contributing this back upstream after hitting 0xc000027b fail-fasts while using TextControlBox as a vendored editor.