fix(c3/s2): correct HW SHA full double-hash instead of software (#34)

[SneezeGUI]

Draft — contains new hardware register sequencing that has not been tested on a physical C3 yet.

Problem

ESP32-C3 mines in software at ~1 KH/s (#34). Cause: single-core SoCs only spawned the software miner task; the HAL HW path was dead code — and it used the same unsupported SHA_H+SHA_CONTINUE midstate restore as the S3 bug (#28), so routing C3 to it would also yield 0 shares.

Fix

• Implements sha256_ll_double_hash_full() for S2/S3/C3 using the legitimate START → CONTINUE flow (no midstate injection), reusing this file's proven helpers.
• Routes single-core builds to it at low priority with frequent yields (so WiFi/Stratum stay alive on the one core).
• Software-verify gate: every HW candidate is re-hashed in software before submitting, so a wrong HW hash can never become a bad share. Worst case if the HW sequence is off = 0 shares + [HW-DBG] output, never a bad submission.
• Boot banner now honestly reports Hardware SHA (C3 envs).

⚠️ Testing (required before merge)

• Flash a real ESP32-C3 with -D DEBUG_SHARE_VALIDATION; confirm [HW-DBG] ... SW verify=PASS and shares at the pool, hashrate well above 1 KH/s.

Closes #34.

[SneezeGUI]

Full review done against main, cross-checked against the on-hardware self-test data from #32. Now marked ready and merged.

What holds up

• The new S2/S3/C3 branch in sha256_ll_double_hash_full (sha256_ll.cpp) is the legitimate flow: block1 → SHA_START, block2 → SHA_CONTINUE, then ll_fill_inter_block() + SHA_START for the second hash. No SHA_H injection — that's the ESP32S3: S3 share validation - SW verify=FAIL hash[28-31] #28 failure mode, avoided.
• The register conventions it reuses are proven on real S3 silicon by Add support for Heltec WiFi LoRa 32 V3 (ESP32-S3 + SSD1306 OLED) #32's boot log (test=1 hw_full_64_from_iv match=PASS, [S3-SHA2] hw_block_match=PASS hw_fast_match=PASS): BE words into SHA_TEXT, START from IV, bswapped digest out of SHA_H, H→TEXT inter-block. C3/S2 use the same programming model.
• Submit path mirrors the proven S3 pattern: software re-hash per candidate, submit only on PASS. A wrong HW hash can't become a bad share.
• Merges clean with main (including the just-merged fix(s3): mine first SHA in software to fix zero-shares (#28, #10, #5) #36) — disjoint paths, S3 dual-core vs single-core fallback. CI 3/3 green, including esp32-c3-supermini.

The change that unblocked merging
The failure mode if C3 silicon disagreed was silent: no env sets DEBUG_SHARE_VALIDATION, so we'd ship "fast hashrate, 0 shares, no logs" — worse than today's ~1 KH/s, which at least mines. Added a one-shot boot self-test: a fixed known vector (all-zero header, nonce 0x0000C4E6, true double-SHA starts 0x000025EE, so both 16-bit early-reject gates pass and full digests are written) through the HW path vs the software reference. On mismatch the boot log says so loudly and the miner task falls back to software (pre-#39 behavior). C3 can now disagree safely and visibly instead of silently.

Also corrected the root-cause comments while in here: the S2/S3/C3 SHA_H digest-state registers expect big-endian state words (espressif/esp-idf#12440) — the old midstate path seeded little-endian — rather than "ignores SHA_H writes on CONTINUE". Same conclusion (no injection here), accurate mechanism.

#34 — @bwhiteman21-commits the flash test is still worth running on real C3 silicon; with this merged a stock build reports at boot whether the HW path passed its self-test, which makes your report a one-liner. Hashrate should jump from ~1 KH/s by a couple of orders of magnitude; if the self-test FAILs on your board, that log line is exactly what I need.