ci: 🧪 add MPI-enabled matrix lanes

[robertodr]

🤖 AI text below 🤖

Build and exercise the C++ MPI variant explicitly on Linux x86-64, Linux ARM64, and macOS, including the combined wide-index configuration. Keep MPI jobs identifiable in status checks and prevent uv from reusing a non-MPI cached build.

CI Workflow and Test Improvements

• Added an explicit mpi matrix axis to CI jobs in .github/workflows/test.yml, enabling parallel testing of both MPI-enabled and serial (non-MPI) builds across Linux x86-64, Linux ARM64, and macOS runners. Also updated environment variables and install logic to conditionally include MPI dependencies and extras. [1] [2] [3] [4] [5]
• Refactored C++ and Python test execution in CI: non-MPI and MPI tests are now run and reported separately, with dedicated Codecov uploads for each. MPI tests are run only when the mpi matrix axis is enabled. [1] [2]
• Updated coverage collection in .github/workflows/qa-analysis.yml to use separate serial and MPI instrumented builds, with aggregation via just code-coverage-collect and just code-coverage-aggregate recipes, and improved artifact handling. [1] [2]

CMake and Build System Changes

• Changed CMake logic to enable MPI support based strictly on the monoprop_ENABLE_MPI variable rather than the presence of the MPI::MPI_CXX target, ensuring consistent and explicit MPI configuration in both the main project and consumers. [1] [2] [3]
• Updated GCC coverage flags to use -fprofile-update=atomic for more robust parallel coverage data collection.

Documentation and Usage Clarifications

• Improved documentation in README.md and AGENTS.md to clarify how MPI and wide-term-index variants are enabled in CI and local builds, the need for MPI initialization/finalization in standalone C++ programs, and how coverage is merged from both serial and MPI runs. [1] [2]

General CI Improvements

• Added unique cache-suffix values to all astral-sh/setup-uv steps across workflows to avoid cache collisions between different CI jobs. [1] [2] [3] [4] [5] [6] [7] [8]

MPI Initialization in Tests

• Updated C++ test snippets to explicitly initialize and finalize MPI around propagator construction, ensuring correct MPI usage in standalone and test code. [1] [2]

Checklist

• Tests added or updated to cover the changes
• Documentation updated (docstrings, docs/, CONTRIBUTING.md) if needed
• CHANGELOG / release notes updated if applicable

AI/LLM disclosure

• I did not use LLM tooling, or used it only privately for ideation
• I used the following tool to help write this PR description:
• I used the following tool to generate or modify code: Pi:gpt-5.6-sol

Important

By opening this PR I confirm that I have read CONTRIBUTING.md and I agree to the terms of the Contributor License Agreement.

Warning

If you're contributing on behalf of your employer, contact cla@algorithmiq.fi to arrange a Corporate CLA.

[github-actions]

Docs preview: https://pr-318.monoprop-docs.pages.dev

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.70%. Comparing base (f2ee0b0) to head (f12ce5b).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #318   +/-   ##
=======================================
  Coverage   97.70%   97.70%           
=======================================
  Files          14       14           
  Lines         742      742           
  Branches       98       98           
=======================================
  Hits          725      725           
  Misses         12       12           
  Partials        5        5           

Flag	Coverage Δ
cpp	97.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[robertodr]

we need to once again change the required checks, since I changed their name again (to make it more compact)

[Panadestein]

Thanks @robertodr! The 600s timeout is a great idea. I wonder if it is possible to diagnose whether that timeout was due to a deadlock, i.e. the test was really not slow but made no progress.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[robertodr]

Thanks @robertodr! The 600s timeout is a great idea. I wonder if it is possible to diagnose whether that timeout was due to a deadlock, i.e. the test was really not slow but made no progress.

@Panadestein I don't know if that is possible, without some instrumentation.