[metal] MTLDevice is thread-safe

[uael]

Description
MTLDevice look like is safe to access from different threads, this remove the Mutex around it. Feel free to close if it's actually not, the Apple documentation is very unclear about that and only notice about the thread safety of the command queue

Testing
Tested manually on iOS.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[uael]

Add an entry to CHANGELOG.md if we are going to merge this

[madsmtm]

I agree that this is thread-safe - you can already safely call MTLCopyAllDevices() and/or MTLCreateSystemDefaultDevice() from any thread, and access the same instances that way.

[cwfitzgerald]

Alright, this would be good to have this, but there are CI issues.

[madsmtm]

For the record, Apple has in Xcode 26 marked the following types as @Sendable in Swift (and objc2-metal marks them as Send + Sync in madsmtm/objc2#762):

• MTLArgument
• MTLCommandQueue
• MTLComputePipelineReflection
• MTLComputePipelineState
• MTLCounter
• MTLCounterSet
• MTLDepthStencilState
• MTLDevice <-- this
• MTLDynamicLibrary
• MTLEvent
• MTLSharedEventListener
• MTLSharedEventHandle
• MTLFence
• MTLFunctionHandle
• MTLIOCommandQueue
• MTLIOFileHandle
• MTLFunction
• MTLFunctionReflection
• MTLLibrary
• MTLLogState
• MTLRasterizationRateMap
• MTLRenderPipelineReflection
• MTLRenderPipelineState
• MTLSamplerState

[uael]

Sorry for the late response. I expect to handle this under 2 weeks