fix(verify): quantize features before SHA-256 for cross-platform hash stability (#560)

[ruvnet]

Summary

Addresses issue #560 — the archive/v1/data/proof/verify.py SHA-256 hash diverges across SIMD backends (Intel AVX vs Apple Silicon NEON) because scipy.fft's pocketfft kernels reorder vectorized FP operations differently per build. IEEE 754 guarantees per-operation determinism, not associativity under reordering, so two "correct" platforms produce values that differ at ULP precision (~1e-14 at our magnitudes), and the SHA-256 of those bytes explodes that ULP drift into a totally different hash.

The fix: round each feature array to 9 decimal places before packing as little-endian f64 and hashing.

⚠ Maintainer action required before merge

archive/v1/data/proof/expected_features.sha256 (currently 8c0680d7d285739ea9597715e84959d9c356c87ee3ad35b5f1e69a4ca41151c6) needs to be regenerated on a canonical CI platform after this change lands. The regeneration command:

python archive/v1/data/proof/verify.py --generate-hash

I would normally do this in the same commit, but:

1. The regeneration changes the published trust-anchor artifact for ADR-028
2. The canonical platform should be the same CI Linux x86_64 used for releases, not my Windows dev box
3. Pre-existing verify.py runtime failures on Windows (pydantic Settings rejecting extra .env fields) prevent me from running the full pipeline locally to extract the new hash

If you want me to push the regenerated hash to this branch once you've run it on the canonical platform, paste the output here and I'll add the commit. Or run --generate-hash and commit the new file yourself before merge.

Probe-side verification

scripts/probe-fft-platform.py (the diagnostic from #607) now emits both sha256_raw (legacy) and sha256_quantized (new). Running on Windows here:

{
  "sha256_raw":       "78b3fb4acb8cc18c3e870f92e29ee98143c7cac4767f2f71b0fc384a82b92f6e",
  "sha256_quantized": "a587792c050cf697366b9bef4611050f9dc3af56624915ab2452c3c11362e79a",
  "quantization_decimals": 9
}

On Linux x86_64 and Apple Silicon arm64 you should observe the same sha256_quantized value (and different sha256_raw). That's the fix doing its job. This isolated-input probe doesn't match the full-pipeline hash from verify.py, but it's a fast cross-platform sanity check.

Quantization decimals rationale

	Value
Observed cross-platform divergence	~1e-14 (ULP at magnitudes of 1-100)
Quantization threshold (this PR)	1e-9 (np.round(.., 9))
Headroom over worst-case SIMD drift	~5 orders of magnitude
CSI phase precision (signal scale)	~1e-3 rad
Headroom below meaningful signal	~6 orders of magnitude

9 decimals is conservative. Could tighten to 11-12 if needed, but the headroom is comfortable and leaves room for future scipy SIMD changes.

Test plan

• python scripts/probe-fft-platform.py on Windows — emits both hashes, sha256_quantized = a58779…
• python scripts/check_fix_markers.py — RuView#560 marker passes (18/18 markers green)
• (Maintainer) Run python archive/v1/data/proof/verify.py --generate-hash on canonical CI platform and commit the regenerated expected_features.sha256
• (Maintainer) Run probe on Linux x86_64 and macOS arm64; confirm sha256_quantized matches across both
• (Maintainer) After hash regeneration, run ./verify on all three platforms; confirm RESULT: PASS on each

Files changed

• archive/v1/data/proof/verify.py — add HASH_QUANTIZATION_DECIMALS=9 constant, quantize in features_to_bytes(), correct the misleading "platform-independent for IEEE 754 compliant systems" claim in the docstring
• scripts/probe-fft-platform.py — emit both raw and quantized hashes for cross-machine diff
• scripts/fix-markers.json — RuView#560 regression marker requiring HASH_QUANTIZATION_DECIMALS and the np.round() call in verify.py
• CHANGELOG.md — Fixed entry under [Unreleased] documenting the change and flagging the expected_features.sha256 regeneration

Closes #560 (after the hash regeneration in the second commit on this branch).

🤖 Generated with claude-flow