Fix half-pixel seam between border-strip and content corner curves

The border-strip bitmap's own corner rounding (corners.rs's blend_
corner_pixel) and the client-content mask's corner rounding
(rounded_corners_pixman.rs's apply_corner_mask) are two independent
implementations that need to trace the exact same circle where a
window's border meets its own rounded content. Their falloff math was
already identical (same smoothstep construction over the same
radius-1..radius+1 band), but apply_corner_mask samples each pixel at
its own center (x as f32 + 0.5) - the standard rasterization
convention, matching the GLES shader used for the winit backend --
while blend_corner_pixel sampled at the raw integer coordinate (x as
f32), a systematic half-pixel offset between the two curves.

round_top_corners/round_bottom_corners had a compensating "- 1" baked
into their own right-edge/bottom-edge center calculation, tuned
against the old, uncentered convention. Confirmed live at extreme
zoom: a small but real right-angle step partway along an otherwise
smooth arc, right where the two curves are supposed to meet --
reported as "squares on the inside corners of each vertex."

Added the missing + 0.5 to blend_corner_pixel and removed the two
compensating "- 1"s (both call sites), which now line up exactly with
apply_corner_mask's own clamp-derived center for the same corner
(width - r / height - r, not width - r - 1 / height - r - 1). All 378
existing tests pass unchanged - none of them assert exact pixel
positions this shifts by half a pixel.

0 files changed, 0 insertions, 0 deletions