Fix exact objective ordering in primal solution storage

[reinhardullrich]

Problem

In exact solving mode, the primal solution pool is still ordered using floating-point objective values. Two different rational objectives can round to the same floating-point value. Consequently, SCIPgetBestSol() can return a worse solution even when another stored solution attains the exact primal bound. With a full solution pool, the insertion position can also cause an exactly better solution to be discarded.

I reproduced the ordering issue on SCIP 10.0.3 and upstream master. In a rational MILP application, two stored solutions differed in objective by approximately 2.29e-37. The second solution matched the exact primal and dual bounds, but SCIPgetBestSol() returned the first. An independent rational verification exposed the discrepancy.

Change

• Compare rational objectives in exact mode when inserting or re-sorting primal solutions, including the original-solution candidate pool.
• Prefer a transformed-space solution over an original-space solution only on an exact objective tie in exact mode.
• Retain the existing floating-point comparisons and tolerance-based transformed-space preference in ordinary mode.
• Add six regression tests and a CHANGELOG entry. No public API or parameter changes.

The comparison handles original/transformed objective conversion and candidates without exact solution data consistently with the existing exact-mode acceptance checks.

Verification

• Unpatched master: four of the six new regression tests fail; two pass; no test crashes.
• Patched master: all six pass, including a one-slot solution pool and transformed-space tie handling.
• All ten unittest-scip-* executables pass, together with their build steps.
• Additional focused tests unittest-event-dual, unittest-limit-solutions, and unittest-limit-primal pass.
• The original application reproducer passes its independent FLINT rational verification against a patched Release build, using SCIPgetBestSol() directly without selecting a different solution from the pool.

Test environment: Linux aarch64, upstream master based on fea16d9, exact solving enabled, SoPlex 8.0.3. Debug and Release builds were used. The full SCIP test suite and a performance benchmark were not run.

Separate Debug-build limitation

The full application reproducer aborts in the installed SoPlex SSVectorBase<double>::forceSetup() assertion (isPlusZero) with both unpatched and patched Debug builds. This is separate from the ordering regression and remains unresolved. The focused Debug tests and the patched Release application run pass as described above; this PR does not claim to fix that assertion.