fix(sheet): apply AUTO header merge context on the right axis

[Sean-Walker0]

Purpose of the pull request

The AUTO header merge strategy validates merge context on the wrong axis in ExcelWriteHeadProperty.headCellRangeList, producing two wrong merges:

1. The case reported in [Bug] Merge error in dynamic header #666 still merges. Writing that issue's exact dynamic head on current main still produces the C2:D2 merged region it complains about: same-name cells (head31/head31) sitting in columns under different parents (head30 vs head40) are joined horizontally, because the horizontal run has no context check at all. feat: introduce header merge strategy for Excel writing #674 added canMergeVertically for this report, but that only guards the vertical path.
2. Equal cells below the first header row no longer merge vertically. The AUTO-only canMergeVertically compares the cell above a vertical run with a cell inside the run (row1-1 vs row2-1 where row2-1 is a run member). A vertical run starting at row >= 1 can only exist when the cell above differs from it (otherwise the run was already consumed from the earlier row), so the comparison is provably always false there. AUTO consequently never merges equal cells under the same parent below row 0 — a regression against the pre-strategy automatic merge and against VERTICAL_ONLY, which both merge them.

Found by code audit of the merge algorithm; both effects verified end-to-end before this change (issue #666's head yields C2:D2; head columns [G,A,A] [G,B,y] [G,B,z] yield no A2:A3).

What's changed?

• Under AUTO, a horizontal run may only extend across cells whose parent labels (the cell above each column, row j-1) are equal — this is the context check the horizontal path was missing, and it fixes the [Bug] Merge error in dynamic header #666 case (head30 vs head40 differ, no merge) while keeping same-parent runs merged (B/B under a merged G run still merge).
• The wrong-axis canMergeVertically check is removed from the vertical path (the method became dead code), restoring automatic vertical merging of equal cells under the same parent (A2:A3 merges again).

VERTICAL_ONLY, HORIZONTAL_ONLY and FULL_RECTANGLE are untouched.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

Verifying this change

AutoHeaderMergeContextTest (both directions):

• autoDoesNotMergeSameNameCellsUnderDifferentParents — the [Bug] Merge error in dynamic header #666 head; red before (same-name cells under different parents must not merge ==> expected: <false> but was: <true>), green after; also pins that first-row runs (head40/head40) still merge;

• autoMergesVerticalRunsBelowTheFirstHeaderRow — red before (equal cells under the same parent must merge vertically ==> expected: <true> but was: <false>), green after; also pins same-parent horizontal merges (B/B under G).

• Existing HeaderMergeStrategyTest: all 5 cases still pass.

• ./mvnw clean package -B -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet: 950 tests, 0 failures, 0 errors.

• ./mvnw -pl fesod-sheet spotless:check: clean.

Notes

• Behavior changes are scoped to AUTO (the default): same-name cells in header rows >= 1 with different parent labels no longer merge horizontally, and equal cells below the first header row merge vertically again. First-row behavior, single-row heads, and the other three strategies are unchanged.
• Orthogonal to open PRs: feat: add composable annotations support #920 and feat: add composable annotation support and meta-annotation processing #1076 touch ExcelWriteHeadProperty only in the annotation-processing constructor hunks, and refactor: Improve the basic javadoc content #1181 only javadoc in the enum — no overlap with headCellRangeList.
• Incidental observations (not touched here): initHeadRowNumber pads ragged head columns by repeating their last value, so a one-level column in a two-level head renders merged with itself (A1:A2 in the [Bug] Merge error in dynamic header #666 file); that normalization predates the merge strategies and is left as is.