Counter ASIC 2.0 status 00:24: job 4 void, sweep 4 running, the M20 era test finding

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/plans/counter-asic-2-status.md

@@ -707,3 +707,9 @@ floor-sweep-3 (00:13:01 to 00:16:57Z, 237 s, exit 0; the v3 server b37defef, the
 | element threshold 2^26 | fees-v1-shards2 | 4,717,439 | 10,291 | 5.7 |
 
 The key-buffer growth fired as designed ("grow key buffer 36,700,160 -> 91,226,112 elements"), the panic class of sweep 2 is closed. Reading, pending the prover-floor agent's write-up: under a 12 GB budget the prototype shard peaks at 13,459 MiB and the adopted v1 shard at 12,915 MiB with 2,089 MiB of idle inside, against about 12,288 MiB reported by a 12 GB card; the 2^26 element threshold brings the v1 shard to 10,291 MiB at 5.7 s against 4.3 (a third slower), which is the first row under a 12 GB card's size; the tier call is the agent's, in docs/analysis/proving-methods.md and the bench log. PC 2 released at 00:17Z; "go PC 2" to agg-cost-pc2-4 at 00:19 (about 20 min; the identities set back to 8 first), then M16, the repro job, the ledger-fixes-0311 suites.
+
+## 00:24 agg-cost-pc2-4 measured nothing (the parser against 0.3.11's state); sweep 4 running; a fork test finding
+
+agg-cost-pc2-4 (00:18:26 to 00:22:05Z, exit 0): card_off and card_on both read "no nvidia card in the state" against 0.3.11's /api/state, so the app's CUDA worker kept running, the pause left 3 miner/worker processes after 120 s, and every phase (D, E20, E18, E16, E0, H) was voided by the job's own double-mining guard; the miner resumed and the prover switched on at 00:22:05Z (the 5090 at 95 percent). Fix assigned to its agent: the parser for 0.3.11's state shape and one refusal before the pause; job 5 takes the slot after sweep 4, M16 and the repro job (about 00:50Z). floor-sweep-4 (mine-and-prove: 2^26 on the v1 and empty shards, 2^25 and 2^27 on the v1 shard, the 5090 mining at full rate, 3 minutes) has its go at 00:23. The prover-floor write-ups are in (prover-floor 251154d: the bench-log entry with the nine rows and the idle-subtracted figures, docs/analysis/prover-floor.md with the model, the hang diagnosis, the patch's three steps and the tier table; the arithmetic for mine-and-prove on 12 GB, 8.2 + 1.8 = 10.0 GB of 12.3 before the display, so the "under 9.0 GB" row is not met alone and sweep 4 decides 2^25); proving-methods 0a00c08 (RISC Zero stays the Apple route only); proving-v1 docs 0a1ad9d (the tier table).
+
+A finding on the shipped fork from the ledger closer (00:21): kaspa-consensus test processes::pruning_proof::igneum_m20_tests::witnesses_are_checked_in_epoch_order_under_their_own_seeds fails on its Mac run of the ledger-fixes-0311 suites (fork fbb0082a on 89dfcb95; 99 passed, 1 failed, 4 ignored): the pruning-proof stand-in (igneum_pow.rs 114) fills era 0 with the genesis hash and the test expects EpochSeeds::v2's era ZERO_HASH (consensus/pow/src/igneum.rs 88). The code read: the node's RPC always reports Some(genesis) in era 0 (consensus/src/consensus/mod.rs 838 to 869) and the miner's legacy walk gives genesis (main.rs 504 to 536), so the proof code matches the node and the test's expectation is the odd one out; seeds_from_info's unwrap_or(ZERO_HASH) differs only against a pre-field node (a mixed case that ends at the three relaunches), and a v2 program reads neither field, so no hash changes. PC 2's combined suite job on the release tree reported kaspa-consensus exit 0, which disagrees with the Mac run; the single test is running on 89dfcb95 on the Mac under the build lock to settle it. Either way the next cut carries the test fix (the expectation, or v2() taking the genesis as its era) and the miner's unwrap_or aligned to genesis.