fix(sparql): compare computed numeric values without hiding fixture errors

[remiceres]

Summary

Companion to corese-stack/corese-core#563 and corese-stack/corese-core#585. Merge only after corese-stack/corese-core#585 has merged into feature/corese-next.

• Compare finite computed decimal/float/double SELECT results by exact decimal value, retaining the datatype and signed floating zero. There is no epsilon, truncation or conversion through floating-point arithmetic.
• Classify expression provenance with the existing native parser; uncertain expressions remain strict. Direct source variables, explicit typed literals, STRDT and unknown BIND/subquery provenance retain RDF-term lexical identity. The numeric comparator does not call Corese's numeric evaluation APIs.
• Keep the official cast-decimal test running and classify only its known four-source-binding oracle defect as CANT_TELL, never PASSED, INAPPLICABLE or UNTESTED. Require the exact test URI, the decimal computed column, 31 rows, the four exact expected/source terms and agreement on every other binding and row multiplicity. Other mismatches remain FAILED. A corrected upstream oracle passes the normal comparator without special treatment.
• Preserve the original JUnit mismatch as the exception cause. JUnit remains failing for this indeterminate test; JSON/EARL and the existing dashboard expose its distinct verdict. Do not change compatibility statuses, skips, CI policy or official fixtures.
• Keep a short explanation and removal condition in the existing exclusions documentation; do not add a standalone numeric-comparison Markdown document.

Why the harness changes are legitimate

Computed numeric values need not have the fixture's arbitrary decimal spelling: see rdf-tests #58, Andy Seaborne and Richard Cyganiak. This does not authorize rewriting stored RDF terms or STRDT results.

In cast/data.ttl, n07–n10 contain 0E1/1E0 as double/float. cast-decimal.rq projects ?v unchanged, but cast-decimal.srx expects 0.0/1.0 in those source bindings. The core preserves the source terms; its four dedicated regression cases verify this. The calculated decimal column and all remaining bindings agree. This exact source-binding defect is distinct from the general formatting discussion; no upstream issue is claimed to resolve it.

Validation

• Full ./gradlew test: 2,989 tests, consisting of 73 passing harness unit tests and 2,916 official cases.
• Official outcomes: 2,657 PASSED, 239 FAILED, 1 CANT_TELL, 2 INAPPLICABLE, 17 UNTESTED. The command exits nonzero honestly: JUnit reports the 239 failures plus the indeterminate fixture, and 19 existing skips.
• All active non-SPARQL suites pass. SPARQL: 738/978 pass, up from 644 before core #563, 94 new passes, zero regressions or missing test identifiers. Of these, eight passes are due to the corrected computed-result comparator; core alone yields 730.
• functions: 75/75 pass; cast evaluation: 5 pass + 1 CANT_TELL, with all seven cast syntax cases also passing.
• Fail-closed unit coverage includes wrong numeric values/types, missing bindings, unrelated-row changes, duplicate/missing affected subjects, row counts, changed expected terms, another test URI and an already-corrected oracle. Numeric tests keep source/STRDT identity, signed zero, datatype, invalid lexical forms and exact values distinct.
• ./gradlew validateEarlReport: 37,474 statements parsed, 15 validation queries passed, JSON/EARL coverage valid.
• SonarLint: 7/7 changed Java files analyzed, zero diagnostics.