systemtests: archive and compare iterations.log for implicit coupling

[AdityaGupta716]

Archives precice-*-iterations.log files from case directories into
iterations-logs/ on every run, and compares them by SHA-256 hash against
a reference sidecar (.iterations-hashes.json) to catch implicit-coupling
regressions.

What this does

• _collect_iterations_logs() finds all precice-*-iterations.log files across each case directory
• __archive_iterations_logs() copies them into iterations-logs/, prefixing with the case name when multiple cases are present to avoid filename collisions
• __compare_iterations_hashes() reads the reference sidecar and fails fast on any hash mismatch, missing log, or unexpected extra log
• Hash check runs before fieldcompare in run() so regressions are caught early with a clear message
• run_for_reference_results() writes the .iterations-hashes.json sidecar automatically alongside the reference tar.gz at reference generation time

Backward compatibility

If no .iterations-hashes.json sidecar exists for a test, the hash check is skipped and the test runs as before. Existing tests are unaffected until reference results are regenerated.

Closes #440

[AdityaGupta716]

hi @MakisH plz review

[MakisH]

This is almost identical to #743 (which was opened first), without referring to it. This is very bad practice (if copied without reference: plagiarism, if both using the same GenAI tool without disclosure: futuristic plagiarism).

I do not mind neither collaboration nor modern tools, but please disclose them. Copying from each other without attribution is not accepted.

[AdityaGupta716]

@MakisH yea they are almost similar but the thing is that i was checking out new issue and the issues where no one was working on but i see that prnjal had opened a pr on the same thing i have worked on (heat exchanger )and i was irritated and i also saw him taking a few more of other ppls pr just adding some improvements on it i was going to point out but i had ur words in mind that said "work on the issue take ur time maintainers will pick the best one" so i didnt point it out cz normally u ask to assign

[MakisH]

@AdityaGupta716 I notice the racing between various GSoC contributors. This is bound to happen, due to the volume, and assigning non-collaborators is not the solution.

The problem in this case is the identical code. This can happen in trivial PRs, but it cannot happen by chance in such complex and long PRs. I have already found such PRs from both you and @PranjalManhgaye that were almost identical:

• this one, where you were second after Archive and compare iterations.log for implicit coupling (fixes #440) #743
• systemtests: fix Python bindings version + robustness (fixes #584) #748, where @PranjalManhgaye was second after systemtests: fix Python bindings version ignored due to tutorial venv (fixes #584) #745

The right thing to do (addressed now to everyone) is to disclose:

• the previous work (other PRs) and the reason that a new one was needed. There are also proper technical ways to do this (e.g., build on top of the respective branch).
• any GenAI tools used, which can lead to such authorship issues.

From my side, I just see duplicate PRs that I need to sort out to review the original one. It is clear to me that GSoC is a place to learn, so this is one thing to learn for the future.

From my side, sorry if I am only seeing this too late, but the PRs I reviewed today were too complex and too many to ignore the similarities.

[AdityaGupta716]

@MakisH sry for this i will keep it in mind but i did review his pr it was nice only difference was Mine returns a (bool, reason) tuple from the hash comparison so the caller gets a specific error message,Mine adds a debug log when no iterations logs are found
his puts the sidecar generation in generate_reference_results.py which might be a better place for it
like normally i would point out things i would like to add in his pr but i was irritated from him so i opened a new one and once more i am sry for this.