Local sign-up for an event at Larpit.fi

With Facebook beyond all hope, we need a place for light-weight event sign-up. This is mostly for the OTHER_EVENT category at Larpit.fi; we anticipate actual larps need to ask more information from their participants and cannot leverage it as such.

We also want to support invite only events in which a signup link with a code is required to sign up.

We want to support both signing up as a signed-in user and signing up with email. When not signed in, signing up and changing one's sign-up status should be verified via email. Unauthenticated users can change their signup status by signing up again with the same email (new verification round).

We use the name "local sign-up" in code to distinguish this from other forms of signing up to a larp (eg. Google Forms). Do not expose that to users, but instead use "sign up at Larpit.fi" or similar.

## Model changes

To record sign-ups of logged-in users, use the existing `RelatedUser` model. Add `LOCAL_SIGNUP_YES`, `LOCAL_SIGNUP_MAYBE` and `LOCAL_SIGNUP_NO` to `RelatedUserRole`. (We want to distinguish `LOCAL_SIGNUP_NO` from absence of sign-up for people to be able to notify the host they can't make it.)

To record sign-ups of unauthenticated users, create an `UnauthenticatedSignup` table with

* `id` (UUID7, also provides creation date)
* `displayName` (text)
* `email` (text)
* `signupStatus` (enum `RelatedUserRole` but accept only `LOCAL_SIGNUP_*`)
* `visibility` (enum `RelatedUserVisibility` but accept only `PARTICIPANTS` and `GM`)
* `verificationCode` (text)
* `verifiedAt` (null – not verified)

Add an enum, `RelatedUserVisibility`, with values `PARTICIPANTS`, `GM` and `ONLY_ME`.

* We may choose to add `SIGNED_IN` at some point, but it's not yet relevant.
* `PARTICIPANTS` shall mean "visible to users with `GM`, `TEAM_MEMBER`, `VOLUNTEER` or `LOCAL_SIGNUP_*` roles".
* `GM` shall mean the GM and the user denoted by `user` in `RelatedUser`, not `TEAM_MEMBER` or `VOLUNTEER`. `ONLY_ME` shall mean the user denoted by `user` in `RelatedUser`.

Add to `RelatedLarp` these fields:

* `visibility` (enum RelatedUserVisibility, default `ONLY_ME`)
* `createdAt` (default now)

Add to `Larp` these fields:

* `localSignupStatus` (enum, values `DISABLED`, `PUBLIC` and `CODE_REQUIRED`)
* `localSignupCode` (string) – if set, sets the code required to be present via eg. `?code=several-municipality-titular-being` query string parameter in order to be able to sign up. (Once an authenticated user has signed up, they no longer need the code.)
* `relatedUserVisibility` (enum `RelatedUserVisibility` but accept only `PARTICIPANTS` and `GM`) – to whom is the participant list available. If `COUNT_ONLY`, only the number of participants (yes/no/maybe) is shown. This defines the ceiling of visibility: individual participants can still choose to sign up GM.

### Rationale for separate `UnauthenticatedSignup` and reuse of `RelatedUser`

Instead of combining these in a `Signup` with a nullable `user` FK, we choose to split authenticated signups into `RelatedUser` and unauthenticated signups into `UnauthenticatedSignup` because this way we are able to leverage the same "my larps" view and other profile-related functionality for signups as is used for other roles.

Unauthenticated users have very limited functionality wrt/ signups (sign up, manage one's own sign-up), so this way the complexity gain is smaller than if sign-ups enjoyed their own profile views.

## Use cases

### Signing up and managing one's sign-up from the larp page

Pages with local sign-up activated should display a prominent sign-up button between the larp info card and fluff text, equal width with the info card. It shall inform the user that this event is using Larpit.fi for sign up (.card-title.text-COLOR to match outline), and of their sign-up status (.card-text):

* This event only accepts sign-ups via a private link. (btn-outline-secondary, disabled)
* You can sign up for this event by clicking here. (btn-outline-info)
* You have signed up for this event! Change your sign-up status by clicking here. (btn-outline-success)
* You have signed up ”maybe” for this event! Change your sign-up status by clicking here. (btn-outline-warning)
* You have signed up ”no” for this event. Change your sign-up status by clicking here. (btn-outline-danger)

Side note: We are currently not prominently displaying cancellation on the larp page. If the larp is cancelled, show a border-danger card with "This larp has been cancelled" where the sign-up button would otherwise be displayed.

When signing up, the user can choose the sign-up to be visible to PARTICIPANTS or GM (ONLY_ME is not an option).

### Folding unauthenticated email verified signups of existing users

Preconditions for folding:

* A user has a verified email address
* An UnauthenticatedSignup (new or updated) is verified with that email address
* OR a RelatedUser signup is being created or managed and an UnauthenticatedSignup exists with the same email address

In these cases, remove any UnauthenticatedSignups for that email address and create or update a `RelatedUser` instead.

This means a RelatedUser signup may be updated via an UnauthenticatedSignup (if the user is too lazy to log in, but completes the email verification).

### Viewing the participant list and other roles

We take down two flies with one swat and implement the participant list as a view for showing all user roles, ie. `RelatedUser`s, related to a page.

The related user / participant list page (and the link thereto, on the larp page) shall be visible according to `relatedUserVisibility`. Unauthenticated users can never view the participant list.

Filter the list according to `RelatedUser.visibility`.

Display the related user list as a table. Include at least the following

* role
* display name
* created at (FormattedDate)
* visibility
* actions
* ❌ remove role (if the GM or own role)
* 📝 manage sign-up or role (if own)

Allow sorting the table by
* default: `role` (enum order) ascending, `createdAt` ascending, `displayName` ascending
* `createdAt` ascending
* `displayName` ascending

In addition to RelatedUsers, show _verified_ UnauthenticatedSignups. Distinguish these visually in a non-obstructive way but sort them among the others.

### Managing a sign-up or other role

Make this a separate page as we'll link to it in several pages. `/larp/ID/roles/ROLE_TYPE/USER_UUID`

Available to the user themselves, and the GM.

The GM and the user can remove the role also from here (redirect to larp page).
The GM can tighten the visibility of the role (ie. make a PARTICIPANTS visible role GM_ONLY) but not the other direction.
The user can change the visibility of their own roles otherwise freely, but they cannot make a LOCAL_SIGNUP_* role ONLY_ME.

### Viewing one's own event sign-ups on the My Larps page

The default filter is still good as-is.

Add event signups (LOCAL_SIGNUP_*) as one item to the type filter.

Allow removing one's own roles and managing sign-ups also from here (add actions column).

### Removing larp roles (`RelatedUser`s)

Two places where this can be initiated: participant list and My Larps page. Share implementation where possible.

One can remove any role of their own. A GM can remove the role of anyone in the larp they are GM in.

Have a confirmation dialog stating the removal cannot be undone. For removing GM roles, warn that the user will lose their edit access. For removing one's own LOCAL_SIGNUP_YES or LOCAL_SIGNUP_MAYBE, suggest changing the signup status to "No" instead.

### Export guest list of an event (export visible `RelatedUser`s and verified `UnauthenticatedSignup`s)

Available only to the GM, not participants. Filter out any ONLY_ME RelatedUsers.

CSV of the fields visible in the related user list, plus email address of `LOCAL_SIGNUP_*` only. We do not generally hand out email addresses of users to the GM in other cases, but the guest list of a local signup event is an exception to this rule.

## Privacy implications

Inform the user upon signing up that the GM will see their display name and email address.

We set the default for RelatedUser.visibility as ONLY_ME. In the future, we will notify users via email that all existing roles will change to GM

## Moderator/admin privileges

Moderators and admins can perform any action a GM can do.

On the related user / participant list page, if the moderator/admin does not otherwise meet RelatedUserVisibility requirements, require an admin override. By convention, we use the `?force=strong` query string parameter to denote an admin is "using the Force". We are geeks, after all.

Start by locating the existing `RelatedUser`, `RelatedLarp`, and `Larp` models, then trace the larp page and My Larps flows mentioned in the issue. The scope spans signup, visibility, participant management, and guest-list export; done means implementing and testing the specified flows and privacy rules across them.

Written by the indexing model from the issue text.