Skip CSRF protection for token-keyed invitation RSVP actions

[mroderick]

Members who open invitation links from mail apps cannot RSVP: their browser withholds the session cookie, so CSRF verification fails with ActionController::InvalidAuthenticityToken (Rollbar 535). The invitation token in the URL already authenticates these actions, so this change removes the redundant CSRF check from them.

Key changes:

• skip_forgery_protection for the six token-keyed RSVP actions: InvitationsController#attend/#reject, WorkshopInvitationController#update/#accept, and WaitingListsController#create/#destroy (scoped only:).
• Each action looks up the invitation by a 128-bit SecureRandom token carried in the URL. The request carries no session authority, which is the only thing CSRF protects — an attacker who cannot guess the token cannot forge the request. PR fix: skip CSRF protection for feedback form submission #2641 applied the same reasoning to the feedback form.
• Regression specs for all six actions: each posts without a CSRF token and asserts the mutation still happens.

Background and scope

Web browsers withhold cookies when they classify a navigation as cross-site. WebKit's Intelligent Tracking Prevention does this for every iOS browser, including Chrome, so members arriving from Mail, Gmail, or Slack reach the invitation page with an ephemeral session. The RSVP POST then arrives without a matching session and fails CSRF verification.

The failure first surfaced on the feedback form and was fixed for that form alone in PR #2641. An audit of all mutating routes found six more token-keyed actions with the same structure; everything else (self check-in, account settings, admin, OAuth) is session-gated and keeps CSRF protection.

Related, not addressed here: the workshop invitation "reject" link mutates via a GET request, which email prefetchers can trigger. That needs its own change.

[olleolleolle]

Perhaps some of the test preconditions could become a nested context.

[mroderick]

Applied: the CSRF-protection toggle now lives in a shared context (spec/support/shared_contexts/forgery_protection.rb) used by all seven specs, and each precondition moved into nested context blocks with let/before. The #update and #accept no-CSRF specs are now nested inside their existing action describes, reusing the file's top-level let(:invitation). The feedback spec from #2641 uses the shared context too.