feat(render): let a pipeline name the colour format it renders into

Campaign V slice V6d, commit 1 of 3. The third contract amendment of the campaign, in the same shape as GpuBlendMode.InverseAlpha (V4c) and GpuVertexFormat.UByte4UInt (V4d): a slice met a wall the pinned contract could not express, and the fix is a reviewed field rather than a backend working around it.

Vulkan's dynamic rendering bakes the colour-attachment format into the pipeline. VkPipelineRenderingCreateInfo has to name it at creation, and a pipeline whose declared format disagrees with the attachment it is used with is undefined. GpuPipelineDescription named SampleCount and nothing else about the target, so slice V6c had no way to ask the question and hard-coded VulkanTextureFormatMapping.CanonicalColorAttachmentFormat for every pipeline it built. It recorded that as a real expressiveness gap rather than hiding it, and named this commit as the honest fix.

GpuPipelineDescription.ColorFormat defaults to Rgba8UnormRenderTarget, which the Vulkan backend already maps to the swapchain's B8G8R8A8_UNORM, so every pipeline written before the field existed keeps exactly the format it was getting. GL ignores the field entirely: a GL framebuffer carries its own attachment formats and a program binds to whatever is attached, so there is nothing for the GL backend to declare. The substitution that makes an offscreen Rgba8UnormRenderTarget resolve to the swapchain's byte order stays — it is what lets a backbuffer pipeline and an offscreen pipeline share one description, and it is invisible above the API because an image is sampled through its format's component mapping.

The contract test asserts both halves that matter: the default is the render-target format (so nothing moves), and the field is really settable (so naming it is not decoration).

App tests 4,057 passed / 3 skipped, up one from the 4,056 baseline. Offline pixel gate against 234fe91d: differing fraction 2.84e-05, 16 pixels of 563,200 compared, inside the documented 15-23 pixel same-commit noise band and about 35x under the 0.001 threshold.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

src/AcDream.App/Rendering/Gpu/GpuPipelineDescription.cs

@@ -126,6 +126,29 @@ internal sealed record GpuPipelineDescription
     /// <summary>Whether the pipeline writes colour at all. False for depth/stencil-only prepasses.</summary>
     public bool ColorWrite { get; init; } = true;
 
+    /// <summary>
+    /// Format of the colour attachment this pipeline renders into.
+    ///
+    /// Vulkan's dynamic rendering bakes the attachment format into the pipeline:
+    /// <c>VkPipelineRenderingCreateInfo</c> has to name it at creation, and a
+    /// pipeline whose declared format differs from the attachment it is used
+    /// with is undefined. GL has no equivalent — a framebuffer carries its own
+    /// attachment formats and a program is bound to whatever is attached — so
+    /// the GL backend ignores this field entirely.
+    ///
+    /// The default is the offscreen render-target format, which the Vulkan
+    /// backend maps to the swapchain's <c>B8G8R8A8_UNORM</c>
+    /// (<c>VulkanTextureFormatMapping.CanonicalColorAttachmentFormat</c>) so
+    /// that backbuffer and offscreen pipelines really do agree. That mapping is
+    /// what made this field necessary and is why the default preserves it: slice
+    /// V6c had to hard-code one format for every pipeline because the contract
+    /// could not express the question, and recorded the gap rather than hiding
+    /// it. Naming the format here is the reviewed fix, in the same shape as
+    /// <see cref="GpuBlendMode.InverseAlpha"/> (V4c) and
+    /// <see cref="GpuVertexFormat.UByte4UInt"/> (V4d).
+    /// </summary>
+    public GpuTextureFormat ColorFormat { get; init; } = GpuTextureFormat.Rgba8UnormRenderTarget;
+
     /// <summary>Sample count of the passes this pipeline is used in. Must match the pass.</summary>
     public int SampleCount { get; init; } = 1;
 }