[DO NOT MERGE] Validation build: fail-fast on IContextCallback dispatch recursion

[Sergio0694]

What this is

A throwaway validation build to answer the open question from #1865: can the IContextCallback dispatch ever be reentered on the same thread? (jkotas: "Are you sure that there cannot ever be recursion that would cause multiple recursive uses of CallbackData on the same thread?")

This instruments the existing dispatch in ABI.WinRT.Interop.IContextCallbackVftbl.ContextCallback with a [ThreadStatic] depth counter. If the dispatch is entered while a previous call on the same thread is still in progress (the reentrancy window is the native ContextCallback_4 call, e.g. due to STA message pumping), it calls Environment.FailFast with a useful message instead of silently continuing.

The goal — per this comment — is to ship a build with this assertion and run it through our tests and the Store to see how common (if ever) this recursion actually happens in real-world scenarios. If it never fires, then the thread-static state optimization from #1865 (without a slower fallback) would be safe.

Notes

• Uses Environment.FailFast (not Debug.Assert) so it fires in Release/Store builds too.
• The counter is decremented in a finally so a legitimate later call on the same thread isn't misdetected if the dispatch throws.
• Only the #if NET && CsWinRT_LANG_11_FEATURES fast path (net8.0/net9.0) is instrumented — that's the path that matters for the Store.
• No public API surface changes (IContextCallbackVftbl is internal).

Not intended to merge — opened to get a preview package from CI.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com