Which invitation a dual-role member receives is decided by pass order, not product intent

从 PR #2867 和 find_or_create_invitation 中的邀请流程开始。阅读 Admin::InvitationController、Event#verified_students 和 Event#verified_coaches，了解 role、verified 和 attending 状态如何在角色切换过程中得到保留。Product 必须先决定哪个邀请优先，以及角色变更是否会重置状态；完成意味着已实现所选行为，并由现有 specs 提供保护。

Summary

PR #2867 made (event/workshop, member) the invitation identity, so a member subscribed as both student and coach now receives exactly one invitation and one email. Which email that is depends on the invitation pass order: Coach first for events, Student first for workshops. The order is an implementation detail, not a product decision.

The specs in PR #2867 pin the surviving role and email subject, so a pass reorder cannot flip this silently — but if product wants, for example, the coach email to always win, that is a separate change.

Decision needed

For a member with both roles, which invitation should win?

1. Keep pass order (current behavior: Coach for events, Student for workshops)
2. Coach email always wins
3. Student email always wins

Related: cleanup of existing duplicate rows (see companion issue), where the same "which one survives" question applies to historical rows.

Related design call (from the PR #2867 review): verified/attending state across role flips

The role flip carries verified and attending state across roles. Admin::InvitationController sets verified: true per row, and Event#verified_students / Event#verified_coaches select by role + accepted + verified. Consequence: a verified Coach invitation flipped to Student (via the self-RSVP role-choice-wins path in find_or_create_invitation) counts in verified_students with no admin action, and the coach-side verified record is gone. Under the old two-row design, verification stayed per role.

If product picks option 1 above (pass order), this needs no action. If product picks option 2 or 3, the flip direction should also decide whether a role change resets verified (and possibly attending).

Flagged by the ce-code-review run on PR #2867 (adversarial + correctness reviewers, confirmed by validation).