Fix waiting-list gaps in reject and destroy, pin promotion behaviour

[mroderick]

Closes three pre-existing gaps in the workshop waiting-list flow and pins two previously unpinned behaviours. Work done from master (before the feat/post-close-rsvp-waitlist rename, so the tested entry point is WaitingList.next_spot; the branch's promote_next keeps this filtering).

Cancelling while waitlisted left a stale entry. WorkshopInvitationController#reject set attending: false but never destroyed the member's own WaitingList row. Worse, the promotion lookup could pick the cancelling member's own entry for the seat they had just freed: that entry was destroyed, the freshly cancelled invitation was set back to attending: true, and the member was emailed a confirmation they had already declined. The entry is now destroyed before the next spot is looked up, so promotion goes to the real next entry for the role.

Destroy of a gone entry 500'd. WaitingListsController#destroy called destroy on find_by(...), which is nil when the entry has already been consumed — reachable by replaying a stale "Remove from the waiting list" link. It now redirects with a notice instead.

Reject needed a session. reject is token-authenticated like accept and update, but was not in the skip_forgery_protection list, so a browser withholding the session cookie got InvalidAuthenticityToken. It is now skipped for the same reason the other token-authenticated actions are.

New pins: cross-role promotion (an older Coach entry is never picked when a Student seat frees up), the promotion email (delivery, its waiting-list body copy, and that exactly one email goes out), and the no-session token-only reject request.

Review notes

Suggested focus:

• The reject fix (app/controllers/workshop_invitation_controller.rb): destroying the cancelling member's entry before computing the next spot is what prevents the self-promotion; the three new specs in its context pin entry removal, no re-acceptance, and promotion of the entry behind.
• The CSRF skip for reject widens what a cross-site POST can invoke. The authenticator is the invitation token, which only email recipients hold; the reasoning mirrors accept, update and WaitingListsController (PR fix: skip CSRF protection for feedback form submission #2641, Rollbar Security warning in Firefox #535).
• Deliberately left out, as branch-owned in feat/post-close-rsvp-waitlist: the closed-waitlist view guard, the destroy gate matrix (custom close vs 3.5h freeze), admin removal between freeze and start, promote_next update-failure path, concurrency, and the promotion/freeze boundary. The admin-removal email assertion also waits for that branch.