Add opt-in PIT mutation testing profile

[renanfranca]

Context

I would like to evaluate adding mutation testing to this project using PIT.

Reference article: https://loiane.com/2026/06/mutation-testing-java-pit/
PIT Maven quickstart: https://pitest.org/quickstart/maven/

The goal is not to replace the current coverage checks, but to complement them by finding behavior that is not effectively protected by the test suite.

Proposal

Add an opt-in Maven profile for PIT mutation testing, for example:

./mvnw -Ppitest test-compile org.pitest:pitest-maven:mutationCoverage

The initial implementation should be conservative:

• Add org.pitest:pitest-maven under a dedicated pitest Maven profile.
• Scope targetClasses and targetTests to the CLI application packages.
• Do not wire PIT into the default verify lifecycle initially.
• Do not enforce a mutation threshold at first.
• Generate the PIT report locally so the team can inspect the initial baseline.

After the baseline is understood, we can decide whether to:

• Add a dedicated GitHub Actions workflow for manual execution.
• Add a scheduled workflow.
• Introduce a mutation score threshold gradually.
• Limit execution to selected modules/packages if full mutation testing is too slow.

Why opt-in first?

Mutation testing can be slower than regular unit tests and may produce surviving mutants that require human judgment. Running it on every normal PR immediately could make the feedback loop worse.

Starting with an explicit Maven profile lets us evaluate the signal-to-noise ratio before deciding how strict the automation should be.

Testing approach

PIT should guide better behavior tests, not encourage implementation-detail tests or a one-test-class-per-production-class habit.

A surviving mutant should lead to a new test only when it reveals missing protection for observable behavior. Equivalent mutants or implementation details should be documented/ignored rather than forcing brittle tests.

Acceptance criteria

• A pitest Maven profile exists and can be executed manually.
• Running the profile generates a PIT mutation testing report.
• The default ./mvnw clean verify behavior remains unchanged.
• The initial configuration is documented in the README or developer documentation.
• No mutation threshold is enforced until a project baseline is reviewed.