CI: fix duplicate builds, add combined unit+system coverage reporting

[mkarlesky]

Summary

Two independent CI improvements.

Fix duplicate CI builds on push + pull_request

All four Phase B PRs from the recent test_invoker refactor (#1218-#1221) each triggered two full CI runs. A prior fix (adf8b885) intended push and pull_request runs for the same commit to share one concurrency group so the second cancels the first, but its group key (ci-${{ github.event.pull_request.number || github.ref }}) evaluates to a different string per event type on the same commit -- the || fallback only ever fires for push, since pull_request always has github.event.pull_request.number set -- so the two runs never actually shared a group. github.head_ref || github.ref_name resolves to the identical bare branch name for both event types, fixing the dedup for real.

Combined unit + system test coverage reporting

Unit tests run in-process (SimpleCov in spec_helper.rb captures them directly). System tests never touch lib/ceedling in-process -- every example shells out to a real bundle exec ruby -S ceedling ... subprocess (SystemContext) against a throwaway, env-stripped Bundler context. Capturing that requires starting SimpleCov inside each child process instead, injected via RUBYOPT (new spec/support/system/simplecov_boot.rb) after Bundler's env-stripping, with SimpleCov.root pointed back at this repo since the child's own CWD is an ephemeral deployed project directory. Both sides accumulate into one shared coverage/.resultset.json; rake coverage:report merges and formats it once after both suites finish.

Two real bugs found and fixed during local verification (not just theorized -- caught by actually running the pipeline end-to-end):

• GitHub Actions composite-action boolean inputs arrive as the string 'false' when disabled, which Ruby treats as truthy -- every gate compares against an exact expected string ('units'/'system') rather than bare presence/truthiness.
• spec_helper.rb is also loaded by the system suite's own outer rspec process (which barely touches lib/ceedling directly -- the real work happens in each child subprocess). A bare on/off check there would make that process also claim SimpleCov's "units" resultset entry and silently overwrite the real unit-test coverage, since SimpleCov's multi-process merging replaces same-named entries rather than accumulating them. Fixed by having the env var's value itself say which suite is instrumenting.
• (Also fixed in the same pass: the throwaway system-test Gemfile added simplecov unpinned, resolving a different version than the main Gemfile and triggering deprecation warnings on stderr that crashed an unrelated, pre-existing .strip-on-raw-stderr code path in compose_failure_report -- pinned to the same ~> 0.22 constraint.)

Everything is gated behind CEEDLING_TEST_COVERAGE, active only on CI's tests-linux Ruby-3.3 leg (reusing that job's existing tool installs rather than adding a separate job). simplecov is a Gemfile-only dependency, never in ceedling.gemspec, matching the existing diff-lcs precedent -- confirmed via an actual gem build that no simplecov dependency or coverage/ content ships in the built gem. coverage/ is gitignored.

Test plan

• bundle exec rspec spec/units -- 2589 examples, 0 failures
• Local coverage dry run: CEEDLING_TEST_COVERAGE=units rspec spec/units/..., then CEEDLING_TEST_COVERAGE=system rspec spec/system/..., then rake coverage:report -- produces one merged coverage/index.html with both "units" and multiple "system-<pid>-<timestamp>" entries in the resultset
• Confirmed CEEDLING_TEST_COVERAGE unset (the normal/default path) produces zero behavior change and no coverage/ output
• gem build ceedling.gemspec from a clean state -- succeeds, confirmed no simplecov dependency and no coverage output in the built gem's file list
• CI: confirm the tests-linux Ruby-3.3 leg uploads a coverage-report artifact and that pushing + immediately opening a PR from the same branch results in one run completing (the other cancelled), not two

🤖 Generated with Claude Code