ci: drop redundant macos-14 runner from matrix

[atom2ueki]

Summary

• Collapse the CI test matrix from [macos-14, macos-15] to a single macos-15 runner.
• Halves macOS runner-minutes per push/PR; the previous matrix wasn't actually testing pinned Swift versions — each image runs against whatever default Xcode it currently ships, which drifts silently over time.
• If we later want to verify the Swift 5.10 floor declared in Package.swift, the right fix is a separate job that xcode-selects a pinned older Xcode, not an unpinned matrix.

Test plan

• CI runs on this PR and the single Swift on macos-15 job goes green (swift build -v + swift test -v).
• Confirm no other workflow references the removed macos-14 runner.

[claude]

Code Review

Verdict: Approve — clean, well-reasoned CI simplification.

What this does

Collapses the CI matrix from [macos-14, macos-15] to a single macos-15 runner, halving macOS runner-minutes without meaningful loss of coverage.

Correctness

• The matrix removal is clean: name, runs-on, strategy, fail-fast, and matrix are all dropped together with no dangling references.
• No other workflow files in .github/workflows/ reference macos-14 — confirmed locally.
• fail-fast: false was only meaningful with multiple matrix entries; removing it alongside the matrix is correct.

Rationale assessment

The PR description reasoning is sound. Both macos-14 and macos-15 runners ship whatever Xcode GitHub Actions happens to bundle at image-build time, so the two-entry matrix never actually provided pinned-version coverage — it was testing against two different unknown Swift toolchains, not a controlled pair. If a Swift 5.10 floor test is needed in the future, xcode-select -s /Applications/Xcode_15.3.app in a dedicated job is the right approach.

Pre-existing issue (not introduced here, but worth tracking)

actions/checkout@v6 on line 22 of ci.yml does not exist — the latest stable release is v4. This has likely been silently resolved by GitHub pinning v6 to v4 internally (GitHub resolves major version tags), but it's technically referencing a non-existent tag and will fail or behave unexpectedly if GitHub ever enforces strict tag resolution. Worth a follow-up PR to pin to actions/checkout@v4.

Summary

• No bugs introduced.
• No security concerns.
• No performance regressions (this improves CI throughput).
• The change does exactly what it says.