[codeling]

What

The integration job had a hardcoded matrix (Joomla 5.4.8 / 6.1.3, 4 combinations), which fell behind when codeling/bfstop moved its matrix into tests/ci/matrix.json and started raising it automatically (now 5.4.10, 6.1.4, 6.2.0; 9 combinations).

A new matrix job in ci.yml:

• picks the bfstop branch (same rule as before: the branch of the same name if it is ahead of main, else main), once, instead of inside every integration job;
• sparse-checks out tests/ci of that branch and reads tests/ci/matrix.json.

The integration job takes both the matrix and the branch from it, so the matrix and the plugin code under test always come from the same checkout. There is now one matrix, maintained in the plugin repository (where joomla-versions.yml raises it and the lint checks the checksums).

Notes

• Both repos now run the same combinations. That means 9 integration jobs here instead of 4. The tests are the same plugin+component tests the plugin repo runs, so this is the coverage that was intended.
• Companion PR in codeling/bfstop updates the texts that said com_bfstop has its own matrix. Its checksum file keeps the 5.4.8 / 6.1.3 entries, so merging order doesn't matter (the old workflow still works against the plugin's main until this is merged).

Checks

• php tests/lint/check-workflows.php (all actions pinned)
• YAML parses; the jq expression yields the plugin's matrix.
• The workflow itself can only be fully exercised by CI on this PR (this branch name also exists in codeling/bfstop, so CI uses that branch there).

---

Generated by Claude Code