fix(wgpu): v29 wire layouts, surface texture on error, pinned pointers in Proc.Call

[YindSoft]

Summary

Four fixes found while building a Go game client on go-webgpu (wgpu-native v29.0.0.0, Windows / DX12). One commit per topic.

1. Wire layouts match the webgpu.h shipped with wgpu-native v29.0.0.0. WGPUBindGroupLayoutEntry gains bindingArraySize (uint32 + padding) between visibility and buffer; WGPUVertexAttribute and WGPURenderPassDepthStencilAttachment gain the leading nextInChain. Without them every later field was read from the wrong offset and wgpu-native panicked with invalid buffer binding type for buffer binding layout at binding 0 and invalid vertex format for vertex attribute: 0. TestABIWireStructAlignment now asserts the v29 layouts instead of the "migration gap" expectations.
2. Adapter strings are copied out of wgpu-native memory. stringViewToString aliased it with unsafe.String; the adapter name read garbage once wgpu-native reused the buffer.
3. Surface.GetCurrentTexture returns the SurfaceTexture on error statuses, and Surface.Present reports a failed wgpuSurfacePresent. Closes Missing Release() in the error path of Surface.GetCurrentTexture() #31. Dropping the texture on Lost/Timeout/Occluded/Error left the swapchain image acquired and the next call aborted the process with Surface image is already acquired. Releasing a texture after a failed present made wgpu-native discard the acquisition a second time (fatal in wgpuTextureRelease), so callers need to know.
4. Proc.Call carries //go:uintptrescapes. Every binding method passes Go structs as uintptr(unsafe.Pointer(&local)). With Proc as an interface the conversion happened in a call that lacked the directive, so the local stayed on the goroutine stack and could move (stack growth, GC shrink) between the conversion and the syscall; wgpu-native then read stale input or wrote its output to the old stack. Reproduced as wgpuSurfaceGetCurrentTexture "returning" a zeroed WGPUSurfaceTexture (status 0) while the texture had really been acquired, followed by an abort in wgpuSurfaceConfigure (SurfaceOutput must be dropped before a new Surface is made), about once every few program starts. Proc is now a concrete struct and Library.NewProc returns *Proc; the directive is only honored on direct calls. Breaking only for code that implements its own Library/Proc.

Testing

• WGPU_NATIVE_PATH=<wgpu-native v29.0.0.0 dll> go test ./... -count=1 passes on Windows 11 with an NVIDIA RTX 3080 Ti (DX12), including the render tests.
• GOOS=linux, GOOS=darwin and GOOS=linux GOARCH=arm64 builds of ./wgpu.
• The client that motivated the fixes (SDL3 window with a wgpu surface, ~600 draws per frame) no longer hits the sporadic startup abort after commit 3.

🤖 Generated with Claude Code

[YindSoft]

Pushed one more commit to this PR: fix(wgpu): pin nested descriptors on the heap (61ba8a6).

It is the same class of bug as the //go:uintptrescapes fix already here, but for pointers the directive doesn't cover. The directive only protects pointers converted to uintptr directly in the argument list of Proc.Call. Many descriptors reach wgpu-native nested instead:

• render pass color/depth attachments
• SetBindGroup dynamic offsets
• the color target Blend of render pipelines
• surface sources
• command-buffer arrays

Their address is stored as uintptr inside another struct, or converted before the call. When those values live on the goroutine stack, a stack move between the conversion and the native call leaves wgpu-native reading stale memory.

pin[T](p *T) *T returns p unchanged but forces the object onto the heap, which does not move. Every uintptr(unsafe.Pointer(&x)) in the package (98 sites) now goes through it. The cost is that those structs become heap allocations.

Tested:

• go vet passes on windows, linux and darwin.
• go test ./wgpu passes with the wgpu-native v29.0.0.0 DLL on Windows.

[Tnze]

Oh, this PR fixs #34

[Tnze]

pin[T](p *T) *T returns p unchanged but forces the object onto the heap, which does not move. Every uintptr(unsafe.Pointer(&x)) in the package (98 sites) now goes through it. The cost is that those structs become heap allocations.

Should use runtime.Pinner instead ?