test: Add regression test for issue #2172 (ValueRangeCache equals vs identity)

[paoloantinori]

Summary

Add regression test for issue #2172 - ValueRangeCache should use .equals() not == for JPA entities.

Background

Issue #2172 reported that ValueRangeCache.Builder.FOR_USER_VALUES used IdentityHashSet (==) instead of HashSet (.equals()) for containment checks. This caused IllegalStateException when:

1. Using filtering value range providers
2. With JPA entities that implement equals() by ID
3. Entities are persisted in one transaction and loaded in another (different object instances, same ID)

Fix Status

This was already fixed in PR #2111 ("refactor: value range cleanup"), but the fix wasn't explicitly tracked as a bug fix for this scenario. The commit message says:

"The solver now implicitly trusts entity equals()."

This PR

Adds a regression test that would have caught this bug in 1.31.0. The test:

1. Creates entities with .equals() by ID (different instances, same ID)
2. Uses a planning variable with a value range provider
3. Simulates pre-assignment (canonical range + entity with "different" but equal value)
4. Verifies the solver doesn't throw IllegalStateException

Benefits

• Documents the specific scenario that was broken
• Prevents regression if someone reintroduces identity-based checks
• Serves as documentation for users with similar use cases (JPA + filtering VRPs)

Related

• Issue Bug: ValueRangeCache IdentityHashSet breaks value range deduplication with JPA entities #2172: Bug: ValueRangeCache IdentityHashSet breaks value range deduplication with JPA entities #2172
• PR refactor: value range cleanup #2111: refactor: value range cleanup #2111
• Commit: 2f99a1d72b

[paoloantinori]

Hi there. As you can guess this has been AI-supported.
I just wanted to add some fully human edited context:

I've stumbled on the bug reported, using the released version. It throws a proper exception. We have put together a fix and a corresponding unit test to show the problem in action.

We've noticed that the fix is already in place, despite being tracked more generically as a refactor. All good, we will wait for the next release. But we still see value in adding the original unit test we had prepared contextually to the fix, to avoid eventual future regressions.

HTH
Paolo

[triceo]

Hello, and thanks for the PR - as you noticed, the fix is already available.

As to the test - this is too low-level to be tested by running the entire solver. Also, adding 200 lines of code for this simple thing seems like an overkill.

Furthermore, all sufficient test coverage is already present, as you can verify in the commit. Therefore I will be closing this PR as not necessary.