blackboard_extend re-fires the straggler DM on the next sweep tick

blackboard_extend double-mails every silent respondent, and now the opener too. CONFIRMED AT SOURCE, v2.58.19, reported by audit-llmmsgsrv-cc and verified by me before filing. Mechanism. stmtBbExtend (:1643-1645) sets straggler_dm_at = NULL. /blackboard_extend then DMs every expected agent that has not written and has not declined, excluding the opener, with "deadline extended - ~Ns left, still waiting on your answer" (:10047-10055). The straggler gate in runBlackboardSweep (:11171) is `age >= BB_STRAGGLER_S && entry.straggler_dm_at === null`, and age is nowS - entry.opened_at - ABSOLUTE from open, never re-armed against the new deadline. Extend is normally called AFTER the straggler mark, because the straggler DM is what tells the opener the board is short. So age is already past the threshold and stays past it, straggler_dm_at has just been nulled, and the next sweep tick (BB_SWEEP_S, 30s default) re-fires the straggler DM to exactly the agents the extend call just notified. MSG-378 made it worse, which is why this is mine to fix. The re-fired straggler block now also builds the opener summary, so the opener receives "As opener you can still act on this... drop_respondent or extend" within 30s of having deliberately chosen to extend. Same "two hub DMs to one agent" class MSG-378 exists to reduce, unguarded across the extend -> next-tick boundary rather than within one tick. MSG-355's own comment frames the straggler_dm_at clear as letting the nudge fire "later in the window the opener just bought". Actual behaviour is immediately. Either the comment or the code is wrong; the code is what ships. CORPUS: cannot prove firings from stored rows - there is no extend event log - but 15 of 60 entries carry a non-default timeout_secs (1500 x2, 2400, 1200, 240 x8, 120, 180 x2), which is consistent with extends having occurred rather than with every opener hand-picking an odd value at open. Treat as live, not latent. 35 entries have straggler_dm_at set. FIX DIRECTION, not yet decided - do not build before choosing: gate the re-fire on time elapsed since the extend (or since straggler_dm_at was cleared), not on raw age from opened_at. Options are a separate column recording the clear, or re-arming by comparing against the NEW timeout rather than absolute age. Whatever lands must keep MSG-355's actual intent - a genuinely long extension SHOULD re-nudge later in the bought window - while not firing on the next tick. Check blackboard_add_respondent for the same pattern before designing; it is the other route that mutates expected mid-flight.