That won't fly: GOARCH=wasm GOOS=js basically makes the Go compiler to produce wasm bytecode from the Go source. To spell this in other words, the Go code gets compiled to WASM bytecode and the WASM API calls instead of CPU-specific machine code and system calls to a particular OS kernel.
On the other hand, cgo is a way to link the compiled C code with the compiled Go code. To compile a program making use of cgo, the go toolchain calls out to a real C compiler (gcc most of the time), which compiles the C parts.
Compiled C code and WASM bytecode exist in different universes and do not know about each other. In theory, a C compiler such as gcc could have a WASM backed—just like go has now—but IIRC this is neither the case nor the Go's WASM backend is taught to somehow handle such a case.
All-in-all, the most typical case for using cgo is interfacing with an already existing library written in C (or exposing a C-compatible API), and most of such libraries usually make profound assumptions about the environment they run in—which typically is a POSIX-compatible OS (with a set of syscalls to handle file and socket I/O and so on).
Hence if you are in a rare position of having the need to link with a "pure" C library—which performs pure data processing and does not communicate with an underlying OS in any way, it might be possible to look at a C-to-Go source-code translator.