Allow post-close cancellations with frozen waitlist progression

[mroderick]

Once a custom RSVP close time passes, members on the main list can still cancel, and each cancellation fills the freed seat from the waiting list until a hard freeze 3.5 hours before the workshop starts. New joins stay blocked from the close time onward. Closes #2990.

• Waiting-list join and leave stop at the earlier of the custom close time and the 3.5-hour freeze. Cancellation and promotion stop at the freeze.
• A cancel frees a seat only when the invitation held one, and promotion takes the first auto-RSVP waiting-list entry in created order.
• Admin removals use the same promotion path, and only while the workshop is in the future.
• Invitation pages hide join, leave, and cancel controls once the matching gate has passed.

Review notes

• Start with the seat claim and the promotion pop. release_seat claims the seat under a row lock, and WaitingList.promote_next pops the head in a transaction with FOR UPDATE SKIP LOCKED. The two must stay consistent: a repeated cancel must not free the same seat twice, and two promotions must not take the same entry. Test suites cannot prove that interleaving, so this part needs the closest read.
• Gate semantics: join and leave use the earlier of the custom close time and the freeze, cancel and promotion use the freeze alone. Actions stop at the instant, not after it.
• Deliberately not done: a reject admitted just before the freeze can still promote and send email after it, because the gate is read once at request start. Re-checking it after the seat claim is a product call. Admin additions ignore the close times. Cancelling from the waiting list keeps the waiting-list entry.

Behaviour by action

Action	Stops at
Join the main list or the waiting list	The earlier of the custom close time and the 3.5-hour freeze
Leave the waiting list	Same as join
Cancel a main-list spot	The 3.5-hour freeze
Promote from the waiting list after a cancel	The 3.5-hour freeze for member cancels, the workshop start for admin removals

The cross-role promotion spec calls promote_next. This change replaces WaitingList.next_spot with promote_next, which confirms the invitation and removes the waiting-list entry in one step.

[davidmillen50]

as we're using update! on line :37 I think it makes sense to also hard error if a record doesn't get destroyed by using destroy! here

[mroderick]

Changed to destroy! in f3f1988. It fixes more than style: promote_next already raises through update! when confirming the invitation fails, so a silent destroy failure would leave the entry on the waiting list while the invitation becomes attending. The entry would stay at the head of the list and a later promotion could confirm the same invitation again. destroy! raises and rolls the transaction back instead.

Thank you 🙏