Vala async methods and GLib MainContext thread-affinity under concurrent requests

Goal

Determine whether a Vala async method resumes on the same thread-default GLib MainContext that started the call when several requests run concurrently, or whether resumption can move to another thread and create latency that appears only under load.

Constraints and uncertainty

Vala async methods compile to state machines driven by GLib main-loop primitives. Vala specifies no language-level memory model or concurrency contract, and it does not guarantee same-thread resumption. Resumption is typically posted to the caller's thread-default context, but the exact context and thread depend on the installed Vala compiler and GLib release.

Does Vala guarantee that async resumption runs on the thread-default MainContext of the calling thread? Can concurrent requests cause resumption to be scheduled on a different GLib MainContext or thread, and what controls that choice? Which Vala and GLib versions document or change this thread-affinity behavior?