Captured from a real `mvn test` run with badSharedConfigAccumulatesTouches NOT yet marked
@Disabled -- i.e. exactly the code shape in the post's "BAD" example, run for real.

-------------------------------------------------------------------------------
Test set: com.ankurm.tutorials.junit.parameterized.SharedMutableArgumentAntiPatternTest
-------------------------------------------------------------------------------
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.017 s <<< FAILURE! -- in com.ankurm.tutorials.junit.parameterized.SharedMutableArgumentAntiPatternTest
com.ankurm.tutorials.junit.parameterized.SharedMutableArgumentAntiPatternTest.badSharedConfigAccumulatesTouches(Config)[2] -- Time elapsed: 0.005 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:569)
	at com.ankurm.tutorials.junit.parameterized.SharedMutableArgumentAntiPatternTest.badSharedConfigAccumulatesTouches(SharedMutableArgumentAntiPatternTest.java:23)

The first invocation passes (expected 1, got 1 -- the shared Config has been touched once).
The second invocation fails with exactly the same assertion, same line number, same test
method -- but now expects 1 and gets 2, because it is the SAME Config instance the first
invocation already touched. Nothing about invocation 2's own code is wrong; the bug is that
sharedProvider() built one Config and handed it to both Arguments.of(...) calls. This is
exactly the failure mode the "fresh instance per invocation" fix in goodFreshConfigIsAlwaysTouchedOnce
avoids -- that test passes all the way through for the identical reason this one fails.