release 0.3.22 section 17: c9e385eb green with the fast-time PASS, the 32,400 floor lost at 00:53 BST and the cause, the named move minute 02:00 BST with the floor cut from it (39,600)

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

docs/plans/release-0.3.22.md

@@ -162,3 +162,7 @@ The 0.3.23 node's heights move Devnet 3's digest to ba75bf6f, and the one-box-at
 **The move minute's gate (main, 23:36 BST):** F9's full 10^5 completes about 00:40 BST, too close to the 00:52 ceiling, so the minute is named on the new pin, the last FETCHED plus ten, and an F9/F1 interim line from the attack-pass lane read inside the five minutes before the minute showing 0 exhausted, 0 panics and 0 redundancy failures over everything drawn so far (16,003 seeds at 23:35 BST, 0 exhausted, max attempt 25; geometric at 0.68, the same shape as sub-version 3's 10^6; exhaustion unreachable by construction with the 256 cap and the deterministic last resort); any non-zero before the minute holds the move and main hears first; the full 10^5 lands as the record line after.
 
 **The Devnet 3 row for the site and this record (main's wording through the Counter lane):** a 0.3.23 node that has not updated falls off at the digest move minute, not at the crossing; the crossing is the class change on nodes already past the digest. Served as: "update before <the fleet's move minute> or the node stops following Devnet 3; class v5 begins at DAA 32,400, about 02:52 BST", the minute filled when the fleet names it.
+
+## 17. The second lost floor and the named minute (00:5x BST, 8 October)
+
+**c9e385eb's gates all green at 23:39:31 BST** (build at gate priority, consensus 134, exec 47, pow 19, p2p-flows 38, core 175, miner 28, both canary sets; the fast-time SUMMARY PASS cross-0324-c9e385eb at 23:49:32 BST: the ladder's rung 1 by signal at epoch 6, class v5 by signal at byte 6 from epoch 8, 11 of 11 program ids equal to the CPU verifier's, the stale node refused 86 of 86, the restart step across the boundary resynced in 28.1 s, four sinks equal). The app side re-pinned to c9e385eb (release-0.3.24 = 25528e4b), the Mac pair (igneumd 29448a07, igneum-miner 9c7b5601) and the DMG 23fa82b7 built under the lock, the Mac entry re-staged in both folders. **The 32,400 floor lost at 00:53 BST:** dn3-g1 read DAA 25,126 at 00:52:03 and 25,169 at 00:52:38, the publish DAA past 25,200 at about 00:53:09 with no move made. The cause: the build-server lane reported nothing from 00:17 BST (the c9e385eb pairs and hive ordered at 23:41, the 0.3.24 host job on PC 1 in the slot since 23:13, 0.3.23 take 3 on PC 2 since 22:58; a read of all three asked at 23:43 and again at 00:57), so the fleet had no pairs to point its move file at and named no minute; the fleet's 22:59 BST proven-share line also unreported (asked four times). **The named minute (the shipper, 00:56 BST, to stop a fourth chase):** the move minute is 02:00 BST on 8 October (01:00Z), or the fleet's last FETCHED plus ten if later but before 02:53 BST; the floor cut from it in one go: program_class_v5_activation_daa 39,600 (epoch 11; the publish DAA at 01:00Z about 29,200, plus 7,200 is 36,400, the next 3,600 boundary), about 04:52 BST, holding for a publish up to DAA 32,400 at about 02:53 BST (a fifty-minute margin past the minute); the same gate set on the new object, the pin line in about 20 minutes, the pairs from it, the move file, the F9/F1 interim read at 01:55 BST (the attack-pass lane sends it unprompted), the apps' entries at or after the minute. If the build-server lane stays silent past 01:05 BST, the fleet moves from the node lane's pair as dn3-g1 and g2 did at 22:30, and the hive and the Windows pair wait on main's word for another builder. The crossing estimate for the record: about 04:52 BST on 8 October (chain id 4464 from that block); the Devnet 3 row's "<minute>" reads 02:00 BST unless the fleet names a later one.