Closes #22093: Run coverage only on a single matrix entry

[pheus]

Fixes: #22093

Add explicit CI job names showing the Python and Node versions, with the coverage job clearly marked in the GitHub Actions UI.

Run coverage only for the designated coverage matrix entry to avoid redundant coverage collection and reporting across the full test matrix.

Also add the YAML document marker and clean up trailing whitespace.

[pheus]

@claude /review Only report on issues of potential concern; we don't need commentary on anything that doesn't require further consideration.

[github-actions]

Claude finished @pheus's task in 2m 39s —— View job

---

Code Review

One potential concern:

Coverage accuracy with --parallel test runner

The "Run tests with coverage" step uses Django's --parallel flag:

- name: Run tests with coverage
  if: ${{ matrix.coverage }}
  run: >-
    coverage run --source="netbox/"
    netbox/manage.py test netbox/ --parallel

When Django's parallel test runner is active, test work is distributed across subprocess workers (via multiprocessing). coverage run only instruments the parent process — worker processes are forked/spawned without coverage tracing. This means a significant portion of test execution goes unmeasured, likely producing a materially incomplete coverage report.

Additionally, there is no coverage combine step between "Run tests with coverage" and "Show coverage report". If any subprocess coverage files are written (e.g. via COVERAGE_PROCESS_START), they won't be merged before reporting.

To get accurate coverage, one of:

1. Drop --parallel from the coverage step so all tests run in-process.
2. Configure subprocess coverage (COVERAGE_PROCESS_START) and add a coverage combine step before coverage report.

Option 1 is simpler but slower; option 2 preserves parallel speed at the cost of extra configuration.

---

Everything else — the matrix include strategy, the conditional step expressions, the job naming, and the YAML cleanup — looks correct and is not a concern.

[pheus]

This PR keeps that behavior unchanged and only limits the existing coverage run to a single matrix entry, which is the scope of #22093. So while the coverage accuracy concern may be real, I don’t think this PR introduces the issue or should expand to solve it.

I’ll open a separate housekeeping issue to track improving coverage collection for parallel test runs.