Fix axis spine corner overextension

[thchr]

🙋‍♂️ As discussed on Slack with @jkrumbiegel, this PR seeks to fix two interrelated things:

1. The axis lines previously (intentionally) overshot the axis corners by spinewidth / 2 to avoid the appearance of a "notch" in the corner. A more elegant way to do this is just to draw the axis lines with a :square cap instead of a :butt cap.
2. Ticks previously started their stroke spinewidth / 2 away from the actual axis centerline. This gives some real surprises, especially with tickalign ≠ 0, since the stroke is then not placed in a natural position at e.g., tickalign = 0.5 or 1. Fix this by starting/anchoring the tickalign = 0 (and tickalign = 1) strokes to the axis' centerline.

These changes are - for me - chiefly motivated by the fact that the existing drawing approach gives headaches if one wants to restyle an exported CairoMakie figure manually in e.g. Illustrator or Inkscape afterwards: if any axis or tick linewidth is changed, or if the figure itself scaled, the "absolute" positioning hacks lead to very visible artifacts (that I have to admit to historically spending way to much time on fixing, by manually realigning all these little lines).

A fuller Claude-generated description below (especially of the ticks-change).

---

🤖 CairoMakie-exported axes don't survive being restroked in Illustrator/Inkscape. Two separate causes, one commit each — the first is a straightforward fix, the second involves a judgement call where input/agreement is needed.

1. Spines overshoot the corners (a48775e)

The spine geometry was extended by 0.5 * spinewidth past each axis corner to fill the corner join. That extension is baked in at axis creation, so restroking the exported figure at a different width leaves the overshoot wrong in both directions.

Now the spine ends exactly at the corner and uses linecap = :square, which fills the corner and scales with whatever stroke width the file is rendered at. Rendering is unchanged.

2. Ticks are anchored to the spine's outer edge (1d0974d)

Tick marks started at 0.5 * spinewidth outside the spine centerline and ran ticksize outward from there (shifted inward by tickalign * ticksize). Same coupling problem: widening the spine's stroke in an editor swallows the tick, narrowing it opens a gap.

Ticks are now anchored on the spine centerline — the one place no stroke width can uncover:

outer_len = (1 - tickalign) * ticksize
inner_len =      tickalign  * ticksize

The drawn mark is exactly ticksize long for every tickalign, which simply slides it across the centerline. spinewidth drops out of the tick geometry entirely.

Both changes live in Makie/, so this fixes all backends, not just Cairo.

The judgement call

Because the mark now starts on the centerline rather than the outer spine edge, half a spine width of it is covered by the spine. To keep existing figures looking the same, default tick sizes are raised by half the default spine width — ticksize 5 → 5.5 and minorticksize 3 → 3.5, for Axis, Colorbar and LineAxis — and tickspace (which drives the tick-label gap and the axis protrusion) subtracts that same half width so labels and the plot area stay put.

Default axes therefore render byte-identically to master (verified on CairoMakie: default, mirrored, trimspine, flipped, and Colorbar, majors and minors). But a figure that sets ticksize explicitly gets marks that appear spinewidth / 2 shorter than before.

Open question: the 5 → 5.5 default is a literal, so it only cancels the change when spinewidth is also default. An axis with spinewidth = 8 and untouched ticksize gets marks appearing 1.5 long (=8/2 - 5.5) instead of 5.0. One alternative is ticksize = automatic, resolved as 5f0 + 0.5f0 * spinewidth, which cancels it for any spine width. I went with the literal because the point of this change is to make ticksize an unconditional stroke length, and a spinewidth-coupled default reintroduces exactly the coupling being removed — but there's a definite trade-off.

What changing tickalign looks like before/after

spinewidth = 12, ticksize = 18. After: the drawn mark is a constant length and tickalign slides it across the centerline; at 1.0 it sits fully inside with its outer tip on the centerline. Before: the mark hung off the spine's outer edge and the buried fraction varied with tickalign.

🤖 Generated with Claude Code

---

Checklists

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• Added an entry in CHANGELOG.md (for new features and breaking changes)
• Added or changed relevant sections in the documentation
• Added unit tests for new algorithms, conversion methods, etc.
• Added reference image tests for new plotting functions, recipes, visual options, etc.
  • My hope is that nothing will move - but we will see in CI