speed package

SweepDrawlessWindow moves a FINISHED, TICKETLESS window's pot to the ops pot, so that money in such a window can leave. PERMISSIONLESS, like Commit. Returns the amount moved.

READ THIS WHOLE COMMENT BEFORE DELETING THE FUNCTION AS DEAD CODE, because in v1 IT IS UNREACHABLE THROUGH EVERY ENTRY POINT and that is deliberate.

WHY IT IS UNREACHABLE HERE. A Draw record comes into existence in exactly one place (getOrCreateDraw) with exactly one caller (Buy), and Buy appends a positive ticket count in the same transaction; a panic anywhere after the record is created reverts the whole transaction, record included. So there is NO SEQUENCE OF CALLS that leaves a window with a record, a zero ticket total and a positive pot. That argument is asserted by the suite (a ticketless window cannot be produced through Buy) and the function's own preconditions are exercised by installing the state directly.

WHY IT EXISTS ANYWAY. It is the shape of AUDIT-2026-09-28.md's fifth fix, and the defect it exists against is the single most common one in that document — SIX of the fourteen findings are "money is in the realm and no path can ever get it out", and four of those six were found by an engineer implementing something else, not by an audit. In the raffle the state is REACHABLE: FundPot credits the live week and creates its record, so a week in which the duel's rake arrived but nobody bought a ticket ends holding money in a Draw that Commit rightly refuses (no tickets), that Resolve and Refund cannot touch (both require Committed) and that FundPot will never revisit (it only funds the live week). ADDING ANY OF THE THINGS THE PACKAGE COMMENT WARNS AGAINST — sponsorship, a rake feed, a jackpot, a rollover — MAKES IT REACHABLE HERE TOO, and the day that happens this exit should already be in place and tested rather than being the thing somebody forgot.

WHERE THE MONEY GOES, AND WHY IT IS NOT "ROLLED FORWARD" INTO THE LIVE WINDOW'S POT.

THE PARAGRAPH THAT STOOD HERE RECOMMENDED A DESIGN TWO AUDITS FOUND EXPLOITABLE, AND THAT IS WHY IT IS QUOTED RATHER THAN QUIETLY REPLACED — AUDIT-2026-09-28.md finding 36. It read:

1"The raffle rolls a drawless week's sponsorship into the live week's pot, AND IT IS
2RIGHT TO: that money is the PLAYERS' side of the duel rake, so handing it to the house
3would take the players' share away from players, and the raffle has a Sponsored field
4that lets the destination week's pot exceed its spend records without breaking
5anything."

EVERY CLAUSE OF IT IS NOW FALSE, AND THE "AND IT IS RIGHT TO" WAS THE DEFECT. The raffle does not roll a dead week's sponsorship anywhere: rolling it into the live week was AUDIT-2026-09-28.md finding 28 (a destination evaluated at call time is a destination the permissionless caller chooses, by choosing when to fire), and the register that replaced it for one day was finding 31 (the caller who opens the destination week is the caller who calls Buy, so they could be its only entrant and capture the whole amount for the price of the house cut). A dead week's sponsorship now becomes a PER-UNIT CLAIM ON THE WEEK IT IS ALREADY IN, payable to the holders of that week's EARNED entries — read the raffle's retireSponsorship and ClaimDeadWeek. There is no destination at all.

SO A READER WHO PORTS SPONSORSHIP INTO THIS FILE MUST NOT PORT THE SENTENCE ABOVE. The half of it that was sound — this money is the PLAYERS' share and must not end up with the house — is satisfied by giving it back to the players who earned it, in place, and never by moving it to a week somebody can pick. This comment is where an engineer adding a rake feed here would look first, which is exactly why a recommendation for a broken design sitting in it is a defect and not untidiness.

NEITHER HALF OF THE ORIGINAL APPLIED HERE IN ANY CASE.

• This realm has no sponsorship and no rake, so there is no players' share to protect: any money in a ticketless window is unattributable by construction — exactly like a stranger's unsolicited transfer, which sweepDonations also sends to opsPot.
• Crediting the live window's Pot would BREAK Pot == sum(spendOf) for that window, which is the identity that makes Refund unable to overdraw and makes a sole entrant's prize exactly their own stake. AuditFailure would then report the live window as short, correctly, and the only way to "fix" it would be to add the Sponsored field and the three mechanisms that come with it — porting the complexity the package comment says not to port, to launder money that cannot exist.

SO opsPot — AND SINCE 2026-09-29 THE TWO REALMS AGREE ON THIS SHAPE RATHER THAN DIFFERING, which is the opposite of what this paragraph used to say. It read: "SO opsPot, WHICH IS A DELIBERATE DEVIATION FROM THE WEEKLY REALM'S CHOICE AND IS NAMED AS ONE ... the routing question ('where does it belong') is answered differently because the money has a different origin." The raffle's own no-claimant branch now sends a dead week's sponsorship to opsPot for exactly the reason given here — there is provably no address holding a unit of that week, so there is nobody to wrong — and it only pays holders when holders exist. Read the raffle's retireSponsorship: the branch is on its EARNED unit total and nothing else. The essential property of the fifth fix is preserved in full either way: money in the realm has a path out, here through WithdrawOps.

Panics if the window is not over yet (a live window may still sell its first ticket, which would make it a real draw whose buyers are entitled to everything in its pot), if there is no record for it, if it sold ANY tickets, if it holds nothing, or — defensively — if it is committed, resolved or abandoned.