feat(invitations): carry chapter_id and workshop_date in invitation job log lines

[mroderick]

Workshop invitation emails (invite_student and invite_coach) are sent as individual ActionMailer::MailDeliveryJob jobs. The canonical job log lines (enqueue, perform_start, perform) carry the serialized job arguments, which today contain only Workshop, Member and WorkshopInvitation gids. Nothing connects an invitation email to its chapter, so log-based tooling cannot attribute invitation volume to chapters without a second data source.

This adds an optional trailing log_context argument to WorkshopInvitationMailer and VirtualWorkshopInvitationMailer#invite_student / #invite_coach. The batch code in InvitationManager passes { chapter_id, workshop_date } (UTC date). Both values are plain attributes on the workshop record the caller already holds, so this introduces no additional database queries. The hash is serialized as part of the job arguments and therefore appears in every canonical log line for the job.

Other callers are unaffected; the parameter defaults to empty.

• send_workshop_emails and send_virtual_workshop_emails batch paths pass the context
• attending, attending_reminder, waiting_list and event invitation mailers are intentionally out of scope

Details

• invitation_log_context in InvitationManager#private builds the hash with safe navigation for workshops without a date
• specs: shared example asserts both mailer methods receive the exact context, and runs a real Delayed::Job enqueue (delay_jobs on) to prove the context survives the serialize/deserialize round trip; mailer specs assert the optional argument does not break delivery
• full suite: 1629 examples, 0 failures (re-run green twice)

Review notes

• Scope: only invite_student/invite_coach get context. attending, reminders and waiting-list lines stay as they are. Say so if those should be covered too.
• The extra serialized argument slightly grows job data (delayed_jobs handler and log volume); it is two small values per email.
• The chapter name is deliberately not logged, only the id.