https://webassembly.github.io/spec/js-api/#run-a-host-function calls a JS function. It may need to wrap that function in appropriate calls to prepare to run a callback and prepare to run script, in order to properly set up the incumbent and entry realms.
I am not familiar enough with the spec to know if this is the case, but the scenario in which this wrapping is needed is if the function is ever passed to user agent code in one place, and then called later, asynchronously. This asynchronicity could be explicit, e.g. by posting a task or microtask; or it could be implicit, e.g. by storing the function in a data structure and then later letting the web developer cause it to be invoked arbitrarily later.
If it is necessary, then you need to store the incumbent settings object at the time of first passing the function to UA code. Then, when it is time to call the function in "run a host function", you prepare to run script with the function's [[Realm]]'s relevant settings object, and prepare to run a callback with the stored incumbent settings object.
This can be tested by looking at the impact on entry/incumbent web APIs of indirecting through "run a host function". For example, see web-platform-tests/wpt#21206 for the impact of indirecting through promise jobs. (The promise tests are likely a bit more complicated than would apply here since they have to deal with the multiple ways of smuggling a function into the promise infrastructure, e.g. thenables vs. fulfillment handlers vs. rejection handlers.)
https://webassembly.github.io/spec/js-api/#run-a-host-function calls a JS function. It may need to wrap that function in appropriate calls to prepare to run a callback and prepare to run script, in order to properly set up the incumbent and entry realms.
I am not familiar enough with the spec to know if this is the case, but the scenario in which this wrapping is needed is if the function is ever passed to user agent code in one place, and then called later, asynchronously. This asynchronicity could be explicit, e.g. by posting a task or microtask; or it could be implicit, e.g. by storing the function in a data structure and then later letting the web developer cause it to be invoked arbitrarily later.
If it is necessary, then you need to store the incumbent settings object at the time of first passing the function to UA code. Then, when it is time to call the function in "run a host function", you prepare to run script with the function's [[Realm]]'s relevant settings object, and prepare to run a callback with the stored incumbent settings object.
This can be tested by looking at the impact on entry/incumbent web APIs of indirecting through "run a host function". For example, see web-platform-tests/wpt#21206 for the impact of indirecting through promise jobs. (The promise tests are likely a bit more complicated than would apply here since they have to deal with the multiple ways of smuggling a function into the promise infrastructure, e.g. thenables vs. fulfillment handlers vs. rejection handlers.)