Open question: Should we use the wit type system to enforce webgpu rules?

WebGPU is written for JS, and is constraint by JS limitations, while wit has a type-system.
Should we use this type-system to enforce WebGPU rules, or should we rather keep the API as close as possible to the official WebGPU API?

Here are a couple of cases where we could enforce rules with the type system:

Take ownership in end/finish method calls

WebGPU has some methods that are meant to be called at the end
GPURenderPassEncoder and GPUComputePassEncoder have .end() methods, and GPUCommandEncoder has the .finish() method, and they're not supposed to be used after calling .end()/.finish().
We could change these to static methods that take ownership, and therefore enforce the rule with the type system.
This would change the way you'd call this method from encoder.end() to GPURenderPassEncoder.end(encoder). A bit clunkier, but enforces the ownership rule.
See also #9

#### Take ownership in requestDevice
requestDevice cnd only be called once per GPUAdapter (see This is a one-time action...)
Similar to the previous point, we could make requestDevice take ownership of GPUAdapter
See https://github.com/WebAssembly/wasi-gfx/issues/43#issuecomment-2678994855 why this is not applicable

BindGroupLayoutEntry entry as variant

The entry in createBindGroupLayout's descriptor, has to have exactly one of the following: buffer/sampler/texture/storageTexture(or externalTexture).
In JS this is a dictionary and the user has to set exactly one of them, but in wit we can simply change it to a variant. That would enforce that exactly one is set.
See also webgpu-native/webgpu-headers/issues/438

Start by comparing the WebGPU API references linked in the issue with the proposed WIT ownership and variant designs, then read #9 and the linked webgpu-native/webgpu-headers issue. Done means reaching and documenting a project decision on whether WIT should enforce these rules or preserve the official WebGPU API shape.