test: capture original WPF shader padding frames and mutations

[wieslawsoltes]

Summary

Independent original Microsoft WPF ShaderEffect padding reference, stacked on #272 at exact 6363c5f. This changes only the existing Windows reference executable, its mandatory reference workflow, and documentation; no native or WPF product implementation, dependency pin, or admission default changes.

• Adds a separate 13-case / 39-replay receipt covering transparent input borders, constant border ink, asymmetric padding, original double identity, source DPI 1/2, normalized UV and derivative registers, complete-frame ImageBrush capture, and same-effect padding zero/expand/reset.
• Preserves every existing 25 arithmetic case, 28 ImageBrush case / 84 replay, 19 arithmetic control, original deadline, strict BGRA assertion, and explicit ARM64 unsupported-software zero-qualified route.
• Saves immutable original inputs and all three new PNG/BGRA replays; a mismatch emits a failed receipt and qualifies no new cases.

Validation

Major implementation commit 4928f3a precedes checks. Three changed C# files pass syntax parsing; the two actual pure oracle files pass 19 unchanged plus 31 new controls (50 total) under bounded CPU-only execution with warnings-as-errors. YAML syntax, original workflow/deadline preservation, unchanged sampler files, and diff checks pass. No WPF type build, native graph build, local GPU, VM, runtime staging, or original Windows pixel execution was performed locally.

The automatic original-Windows workflow must execute this exact head on both architectures. Native padding fixture variants 0–8/11 at 8a14271 are a separate paired implementation, not a qualified dependency. Native fractional/cropped rejection cases remain unsupported. Original software pixels do not qualify native hardware/provider/package/application behavior.

Dependency and remaining gates

Depends on #272. Keep this draft stacked while its independent Windows references run; defer manual full native Build until the dependency is ready/current, then require an exact successful whole Build and all required checks before merge. No source #551 pin change or failed producer staging.

[wieslawsoltes]

Read-only original hardware UV reconciliation (no reference or native changes): immutable LibreWPF 381194e1 prepares a unit XY/UV0 quad in WpfGfx/core/hw/d3ddevice.cpp:6576–6636; ShaderEffectsVS.fx passes UV0 through unchanged. ShaderEffect.cpp:226–244 applies destination state and final-destination SetupVertexTransform; Effect.cpp:178–202 composes extent × WorldToDevice × saved projection. The projection in d3ddevice.cpp:4020–4056 contains the D3D9 half-pixel correction, so viewport conversion gives rasterX = L + uW − 0.5; the integer D3D9 pixel x therefore receives u = (x − L + 0.5) / W (and likewise y). This supports the unchanged native pixel-center expectation, distinct from the observed SoftwareOnly integer phase.

Padding is narrowed into local float edges first (ShaderEffect.cpp:172–179), then scaled into the full retained frame (drawingcontext.cpp:3717–3735, 4912–4923). The DPI2 case with halved logical content/padding still has physical frame (12,14,32,16), with a half PHYSICAL pixel phase. At (14,14), the hardware-source prediction is R20/G8, versus the measured software R16/G0.

This is source-derived evidence, not executed hardware parity. A genuine original hardware target with HardwareOnly must still verify the complete UV raster, DPI1/2, translated origin and unchanged final clipping; the existing SoftwareOnly RenderTargetBitmap reference does not satisfy that gate. No source/receipt alteration, native build, VM, GPU execution or runtime staging occurred. Microsoft raster convention: https://learn.microsoft.com/en-us/windows/win32/direct3d9/directly-mapping-texels-to-pixels