Fix dark/faded Metal rendering: use premultiplied alpha blend factors

[Copilot]

The fragment shader outputs premultiplied alpha (rgb * alpha, alpha) but the blend state was using SourceAlpha, causing double-multiplication by alpha and darkened output.

• Blend factors (MetalGraphics.cs): Changed SourceRgbBlendFactor and SourceAlphaBlendFactor from SourceAlpha to One — standard premultiplied alpha over compositing.

// Before: source.rgb * source.a (double-multiplied since shader already premultiplies)
SourceRgbBlendFactor = MTLBlendFactor.SourceAlpha,
// After: source.rgb * 1 (correct — shader output is already premultiplied)
SourceRgbBlendFactor = MTLBlendFactor.One,

• Acceptance test format mismatch (AcceptanceTests.cs): Test was creating render targets with RGBA8Unorm while the pipeline expects BGRA8Unorm. Now uses MetalGraphics.DefaultPixelFormat.

[praeclarum]

Since SaveDrawing is blitting the texture to a CGBitmapContext with a fixed pixel format it seems dangerous to just use DefaultPixelFormat? Or am I misunderstanding DefaultPixelFormat? I'm not necessarily asking for a change but I do need a n explanation. DefaultPixelFormat is seeming like a bad idea haha.

[Copilot]

You're right — the original PremultipliedLast in SaveDrawing expects RGBA byte order, so blindly using DefaultPixelFormat (BGRA) for the texture would swap R and B during readback.

Fixed in 9c1bbac: SaveDrawing now selects CGBitmapFlags based on DefaultPixelFormat — uses PremultipliedFirst | ByteOrder32Little for BGRA, or PremultipliedLast for RGBA. This keeps the texture format in sync with both the pipeline and the bitmap readback.

The texture format change itself is still needed because Metal requires the render target format to match the pipeline's color attachment format — the original RGBA8Unorm mismatched the pipeline's BGRA8Unorm.