fix(proof): correct atomic-unit thresholds + mirror SetUint64 to prover

[DHEBP]

Summary

Two related arithmetic-correctness fixes on the proof-validation path, both follow-ups to PR #14.

• proof/proof_validation.go: the hard-cap and reasonable-amount thresholds assumed 1 DERO = 1,000,000 atomic units, but DERO uses 100,000 atomic units per DERO (matches globals/globals.go:295 and the GetInfo RPC supply conversion at rpc_dero_getinfo.go:81). The threshold constants were therefore 10× too high — the hard-cap check effectively triggered at ~220M DERO instead of the documented 22M. Reorder the const block so atomicUnitsPerDero is defined first, then rewrite each threshold as X * atomicUnitsPerDero so the conversion factor is explicit at every use site. Same correction applied to the largeThreshold local variable in DetectSuspiciousProofPatterns.
• proof/proof_validation_test.go: four test cases referenced the buggy constants by value. After the constant correction, those amounts would correspond to 210M / 230M / 500M DERO — outside the labelled intent. Update the four affected test amounts and tighten the labels.
• cryptography/crypto/proof_generate.go: mirror PR feat(explorer): proof validation security + modern UI refresh #14's verifier-side SetInt64(int64(amount)) → SetUint64(amount) hardening to the prover side. The previous pattern is bounded in legitimate use (transfer amounts and balances cap well below 2^63) and only causes self-DoS if it ever fires, but leaving the asymmetric pattern in place is forensic-screenshot bait once readers compare verifier and prover. Drop the misleading // this should be reduced comments — at this scale (values bounded by 2^64) the bn256 group order (~2^254) makes modular reduction a no-op.
• Warning 4 in DetectSuspiciousProofPatterns: the hardcoded 1_000_000_000_000 literal flagged exact multiples of 10M DERO under the correct conversion. Restore the original intent — exact multiples of 1M DERO — via 1_000_000 * atomicUnitsPerDero.

Background

atomicUnitsPerDero = 100_000 is correct (confirmed against the canonical decimals constant). Where PR #14 went off-by-10× was in the threshold constants themselves:

• 21_000_000 DERO × 100_000 atomic/DERO = 2_100_000_000_000 atomic. The constant had 21_000_000_000_000 — 10× too high.
• Same arithmetic error for maxReasonableAmountAtomic, currentSupplyApproxAtomic, and the local largeThreshold / Warning 4 literal.

Practical exploitability: none as a chain-attack. The primary gate that rejects fabricated impossible amounts is the cryptographic commitment match at proof/proof.go:99. The validator at proof/proof.go:54 is an early-rejection shortcut, not a defense layer. The off-by-10× error meant the shortcut let through fabricated proofs with displayed amounts up to ~220M DERO (which the crypto path rejected on the commitment-match check), instead of cutting them at 22M as the comments and error messages claimed.

But the constants disagreed with their own labels and the test labels by 10×, which produces misleading rejection messages ("amount X DERO exceeds DERO hard cap (21M)" computed from a threshold that's actually 210M). This PR aligns the math with the labels and tightens the prover/verifier symmetry.

Risk

Minimal. The validator's behavior changes only in the band of amounts between the old buggy threshold (~220M DERO atomic) and the corrected threshold (22M DERO atomic). No legitimate transfer can fall in that band (the on-chain hard cap is 21M DERO), so the only inputs affected are intentionally fabricated proof strings — which is what the validator exists to reject.

The prover-side SetUint64 change has no behavioral effect for legitimate amounts (which are far below 2^63); it makes prover signed-overflow behavior consistent with the post-PR-#14 verifier.

The Warning 4 change affects only the (currently unwired) DetectSuspiciousProofPatterns function — no user-visible effect in community-dev. Included for arithmetic consistency and to align with the matching change in DHEBP/HOLOGRAM @ a8902d9.

Test plan

• go build ./proof/... ./cryptography/... — passes
• go test ./proof/... — passes (all 11 existing wraparound + hard-cap test cases pass against the corrected constants and the updated 4 test amounts)
• go vet ./proof/... — clean (pre-existing unreachable code warning in proof_innerproduct.go:309 is unrelated and untouched by this PR)

Notes

• Sibling fix shipped on the HOLOGRAM repo (which has its own independent copy of proof_validation.go) via DHEBP/HOLOGRAM @ da6f814 and @ a8902d9.
• Does not wire DetectSuspiciousProofPatterns into any display path — it remains unwired in community-dev. Either deleting it as dead code or wiring it into the explorer's display layer is a separate follow-up if desired.
• Two commits to make review easier — constants/tests/prover hardening in commit 1, Warning 4 in commit 2.