[AI Task] Preserve stack traces in Tizen sync context Send and deduplicate Send/Post dispatch

[JoonghyunCho]

Summary

TizenSynchronizationContext.Send and TizenUISynchronizationContext.Send captured exceptions thrown by the callback on the main-loop thread and rethrew them on the calling thread with throw err;, which destroys the original stack trace — debugging showed only the Send call site instead of the real failure point inside the dispatched callback. This PR rethrows via ExceptionDispatchInfo.Capture(ex).Throw() (the standard BCL technique for cross-thread exception marshaling), switches the per-call rendezvous from the kernel-object ManualResetEvent to ManualResetEventSlim, and unifies the two classes' duplicated Send/Post implementations — which differed only by the GLib context flag — into one internal helper.

Changes

• src/Tizen.Applications.Common/Tizen.Applications/TizenSynchronizationContext.cs — Post/Send now delegate to a new internal SynchronizationContextDispatcher class (co-located in this file, following the GSourceManager.cs convention), which holds the single shared implementation: ExceptionDispatchInfo-based rethrow, ManualResetEventSlim rendezvous, and a useTizenGlibContext parameter.
• src/Tizen.Applications.Common/Tizen.Applications/TizenUISynchronizationContext.cs — Post/Send delegate to the same helper with useTizenGlibContext: true; removed the duplicated implementation and unused usings, and restored the missing trailing newline.

Mode

Refactoring

Verification

• Build: passed (dotnet build on Tizen.Applications.Common — 0 errors)
• Tests: N/A
• Benchmark: skipped (sdb error: no device attached)

Public API signatures are unchanged (Send/Post overrides intact, helper is internal). The same exception object is thrown as before — only the original stack trace is now preserved.

Fixes #7737

[JoonghyunCho]

⚠️ Benchmark skipped: Encountered an issue with sdb device connection/deployment/execution, so the benchmark could not be run. Manual benchmark verification is required. Error: no sdb device attached (sdb devices returned an empty list).

[JoonghyunCho]

🤖 [AI Review]
🟡 Suggestion: Send still deadlocks when called from the main-loop thread itself — the posted callback can never run while mre.Wait() blocks the loop (pre-existing, but now fixable in one place thanks to this centralization). WinForms/WPF contexts invoke the delegate inline in that case; doing the same here needs reliable main-thread identification, e.g. capturing the thread ID when the context is installed:

if (Environment.CurrentManagedThreadId == s_mainThreadId)
{
    d(state); // already on the loop thread; run inline instead of blocking on our own queue
    return;
}

[JoonghyunCho]

🤖 [AI Review]
Addressed in 0d4f958. Each context captures its installing thread's ID (per-instance rather than a single static, since TizenSynchronizationContext and TizenUISynchronizationContext dispatch to different loop threads), and Send now runs the delegate inline when already on that thread.