Fix the CI failures from #320: SpotBugs findings and a GPU-only assumption on pocl

[bernardladenthin]

Summary

Fixes the two failures that turned main red immediately after #320. They are unrelated to each other, and both were reachable on a developer machine — I verified #320 with mvn test, spotless:check and reuse lint, and never once with spotbugs:check.

• SpotBugs: 14 findings → 0. Ten are fixed rather than silenced; four are suppressed with rationale, following the precedent already in spotbugs-exclude.xml.
• One test failed on the pocl CI job because it assumed "an OpenCL device is available" where it needed "a GPU is available". Auto-discovery deliberately sweeps GPUs only — pocl exposes a CPU device — so the test asked the tuner to find something it correctly filters out.

What was actually wrong

Finding	The real defect
EI_EXPOSE_REP / REP2	DeviceSweep took a live slice of the sweep's own accumulator and handed the same list back out. Its compact constructor now copies.
OCP_OVERLY_CONCRETE ×3	Parameters widened to Collection / Iterable — all the bodies ever needed.
WEM_WEAK_EXCEPTION ×3	Exceptions now carry the device, the platform/device indices or the configured key-producer counts instead of a fixed sentence.
FORMAT_STRING_MANIPULATION	withSignificantDigits assembled "%." + decimals + "f". A switch over literal formats also spells out that only three shapes exist.
PZLA_PREFER_ZERO_LENGTH_ARRAYS	The device-info query returned null on refusal; an empty array is rejected by the same length checks, so the null bought nothing.

Suppressed with rationale: three EXS_EXCEPTION_SOFTENING_NO_CONSTRAINTS where Jackson's checked exception is wrapped while serialising POJOs this project owns end to end — a failure there means the POJO shape and the mapper have gone out of step, a programming error no caller could act on — and one ENMI_ONE_ENUM_VALUE for a stateless singleton, where a second constant would have no meaning.

The test failure is the better lesson

run_noProducerConfiguredButGpuPresent_sweepsTheDetectedDevices was guarded only by an OpenCL 2.0+ device is available. But an OpenCL device is not necessarily a GPU, and excluding CPU runtimes from auto-discovery is deliberate and tested behaviour — a CPU runtime duplicates what producerJava already does. This project's own OpenCL CI job runs on pocl, which exposes exactly one CPU device.

So the test failed on its own premise, not on the behaviour under test. It now also assumes hasGpuOpenCLDevice() — a helper that already existed in OpenCLPlatformAssume and that I did not look for.

Test plan

• spotbugs:check reports 0 bugs (was 14), reproduced locally with the same command the code-style job uses: mvn -DskipTests -Denforcer.skip=true compile spotbugs:check
• 127 tests pass across TuneConfigurationTest, StatisticsTest, OpenCLDeviceTopologyTest, ConsumerJavaTest, ConfigFixturesParseTest and the architecture rules
• spotbugs-exclude.xml parses as XML — a malformed filter silently disables every suppression
• REUSE 487/487, spotless:check clean
• CI is green on this branch

Not verified here: the pocl job itself. There is no pocl runtime on this machine, so the assumption fix is reasoned from pocl exposing CL_DEVICE_TYPE_CPU and from the failure message, not observed. This is exactly the class of gap that produced the bug, so it is worth watching the test-opencl job on this branch rather than assuming.

Related issues / PRs

Refs #320

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes

[sonarqubecloud]

Quality Gate failed

Failed conditions
52.2% Coverage on New Code (required ≥ 80%)
C Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE