SemanticCompute v1.17.0

SemanticCompute v1.17.0 — the doctor learns float64

A minor: one capability, long asked for and now cleanly scoped. The longest-standing consumer question
— asked three times by a Double-native package whose 20+ family mappings could not be parity-checked
end to end — received its decision and its implementation the same day.

Added

Doctor-level float64 comparison. SLCompatibilityDoctor.compareDoubleBuffers judges two float64
buffers at FULL precision: bit identity under exact, absolute/relative bars evaluated in Double, and
ulp(n) counted in DOUBLE ULPs (slDoubleULPDistance, new) — one float32 step at 1.0 spans ~2²⁹ of
them, which is the resolution gap this surface exists for.

The scope is the design. Families and lowerings remain float32 — a verdict about whether two arrays
agree is not a claim about what a GPU will do with them, and conflating those is what made the original
silent-narrowing bug possible. A float64 result carries that scope in its own precision field rather
than leaving it to inference.

Over MCP: sc_check_parity gains precision: "float64". The float32 exact refusal — which was
always correct — now names the float64 path as its first remedy. An unknown precision refuses rather
than defaulting, per the house rule that a typo must never become a false green.

The pinned defining case is the requesting consumer's own: two Doubles differing by 6.66e-16 —
identical as float32 — are seen, measured exactly, and tolerable only under a knowingly-stated double
bar.

Verification surface: 1,196 tests in 258 suites; the kernel-compile sweep covers 365 programs across
224 lowerings, 0 failed. Four lowering targets, three executed in-core (Metal, portable C, WGSL) plus
the externally verified CUDA runner.