oh also say things about encoders

doc/articles/Multithreading.md

@@ -5,7 +5,9 @@
 Where multithreading is supported:
 
 - The implementation must provide the documented @ref ThreadSafety guarantees.
-- All objects must be freely usable on any thread at any time.
+- All objects must be freely usable on any thread at any time, except:
+    - Where APIs are specified as being non-thread-safe, they must mutexed.
+    - The exceptions for Wasm, below.
 - State must be thread-global, except where otherwise defined.
     - For example, buffer map state is thread-global, and mapped memory ranges may be used from any thread.
     - Note: Error scope state is thread-local. See @ref ErrorScopes.
@@ -19,7 +21,12 @@ Initial `webgpu.h` implementations will not be multithreading-capable.
 
 Wasm-on-JS implementations *may* implement multithreading by proxying calls to a single JS "thread", as long as the C API behavior is conformant.
 
-Once the JS API is multithreading-capable, there are still expected to be some thread-local behaviors (such as buffer mapping state being thread-local). These limitations may still be exposed, but multithreading-capable Wasm-on-JS implementations may also avoid exposing them where feasible (e.g. by proxying all mapping calls to a single JS thread).
+Once the JS API is multithreading-capable, there are still expected to be some thread-local behaviors:
+
+- Buffer mapping state may be thread-local.
+    - Implementations *should* make this state thread-global if feasible (e.g. by proxying all mapping calls to a single JS thread).
+- Any object which is not thread-shareable in JS may not be thread-shareable in Wasm (e.g. encoder objects may not be thread-shareable, similar to how they are not thread safe in `webgpu.h` in general).
+    - Implementations *may* make them thread-global but this is not expected to be performant.
 
 ## Thread Safety {#ThreadSafety}