docs(golang): say why the auth guest's block_on is wasm32-only

On native targets stack-auth now spawns a token refresh onto the current
Tokio runtime. futures::executor::block_on provides none, so token and
refresh in the auth guest would panic on the first refresh in a native
build. Today only the wasm32 abi exports reach them, where stack-auth
refreshes inline and block_on is sound.

A cfg(target_arch = "wasm32") gate would leave their helpers dead on the
native test build, so record the constraint where block_on is imported
instead, before a native test finds the panic by accident.

Author: coderdan

languages/golang/auth/guest/src/auth.rs

@@ -6,6 +6,13 @@ use std::cell::{Cell, RefCell};
 use std::collections::HashMap;
 
 use cts_common::Crn;
+// Sound on wasm32 only. There stack-auth runs a token refresh inline, so a
+// plain executor can drive `get_token` to completion. On a native target
+// stack-auth spawns the refresh onto the current Tokio runtime, and
+// `block_on` provides none, so the first refresh panics (and inside a
+// current-thread runtime it would block the thread the task needs). `token`
+// and `refresh` below are reached only through the wasm32 `abi` exports. A
+// native build, a test included, must not call them.
 use futures::executor::block_on;
 use serde::Deserialize;
 use stack_auth::{