Add event visibility fields and validation (backend)

[trista-chen-29]

This PR adds backend support for event visibility as part of #36.

Changes

• Added new fields to Event:
  • visibility (public | private)
  • minimum_visible_role (member | officer | admin, for private events)
• Kept status (draft | published | closed) separate from visibility
• Added:
  • default values (draft, public) on event creation
  • validation for status, visibility, and minimum_visible_role
  • PATCH support for visibility-related fields by applying incoming changes onto the existing event and validating the merged result
• Ensured:
  • public events cannot have a minimum_visible_role
  • private events must define a valid role
  • switching an event to public clears minimum_visible_role

Design Decisions

• Separated status (draft/published) from visibility (public/private) to support overlapping states such as draft + private
• Introduced minimum_visible_role instead of hardcoding role logic to keep the backend flexible and aligned with Clark roles
• Defaulted new events to draft + public for a safer creation flow
• Kept visibility enforcement out of backend for now; Clark will handle filtering/rendering based on user role

Verification

Tested locally end-to-end after applying the empty _id fix (#53):

• Example terminal verification:

curl -X POST http://localhost:8002/events/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Visibility Test Event",
    "date": "2026-04-20",
    "time": "18:00",
    "location": "Student Union",
    "description": "Testing defaults",
    "admins": ["user123"],
    "registration_form": [],
    "max_attendees": 50
  }'

{"id":"69ddf2365aeab4a1f0851d93","name":"Visibility Test Event","date":"2026-04-20","time":"18:00","location":"Student Union","description":"Testing defaults","admins":["user123"],"registration_form":[],"max_attendees":50,"created_at":"","status":"draft","visibility":"public"}

curl -X PATCH "http://localhost:8002/events/69ddf2365aeab4a1f0851d93?user_id=user123" \
  -H "Content-Type: application/json" \
  -d '{
    "visibility": "private"
  }'

{"error":"minimum_visible_role is required when visibility is private"}

curl -X PATCH "http://localhost:8002/events/69ddf2365aeab4a1f0851d93?user_id=user123" \
  -H "Content-Type: application/json" \
  -d '{
    "visibility": "private",
    "minimum_visible_role": "member"
  }'

{"message":"event updated successfully"}

curl http://localhost:8002/events/69ddf2365aeab4a1f0851d93

{"id":"69ddf2365aeab4a1f0851d93","name":"Visibility Test Event","date":"2026-04-20","time":"18:00","location":"Student Union","description":"Testing defaults","admins":["user123"],"registration_form":[],"max_attendees":50,"created_at":"","status":"draft","visibility":"private","minimum_visible_role":"member"}

curl -X PATCH "http://localhost:8002/events/69ddf2365aeab4a1f0851d93?user_id=user123" \
  -H "Content-Type: application/json" \
  -d '{
    "visibility": "public"
  }'

{"message":"event updated successfully"}

curl http://localhost:8002/events/69ddf2365aeab4a1f0851d93

{"id":"69ddf2365aeab4a1f0851d93","name":"Visibility Test Event","date":"2026-04-20","time":"18:00","location":"Student Union","description":"Testing defaults","admins":["user123"],"registration_form":[],"max_attendees":50,"created_at":"","status":"draft","visibility":"public"}

Notes

• Depends on Fix empty event _id generation in CreateEvent #53 for full end-to-end verification
• Builds on the existing event update flow from Allow updating events #35
• Does not implement the broader update-permission logic discussed in Determine who can update events #41
• Frontend support in Clark will follow in a separate PR

[steeevin88]

similar to Emily's PR, this PR adds a change to the Event struct which will break existing logic i think (ex. create event doesnt' expect this field)

i could be completely wrong but could you double check to confirm this? if it does break stuff then maybe we should make a preliminary PR before this PR that adds the new field to the Event struct (ensuring that anything that uses the Event struct properly uses the new field). and then we can merge this PR after

[steeevin88]

this lgtm, is there anything that this is blocked by? if not then feel free to merge + make the corresponding frontend changes in Clark (after rebasing ofc)

Khoa's PR adds the edit event page, once this is merged you'll have to edit the page to allow editing visibility as well

[trista-chen-29]

I was able to verify the visibility validation logic on the backend with the following observations:

• When creating an event without explicitly setting these fields, the backend correctly defaults to status = draft and visibility = public.
• When attempting to create a private event (visibility = private) without providing minimum_visible_role, the request is rejected as expected by the validation logic.

However, I was not able to fully test the PATCH/update flows end to end due to a separate issue I encountered in CreateEvent():

• Newly created events are being inserted into MongoDB with an empty string as the _id (i.e., _id: "").

• This causes subsequent operations (such as creating additional events or updating existing ones via PATCH) to fail, since the ID is not valid or unique.

• I confirmed this directly in MongoDB using:

  db.events.find({ _id: "" }).pretty()

  which returns the inserted event with an empty _id.

Because of this, I couldn’t reliably test updating visibility (e.g., switching between public/private or validating minimum_visible_role on PATCH), since the event IDs are not usable.

This issue appears to be independent of the visibility validation changes in this PR and likely needs to be addressed separately (e.g., ensuring _id is properly generated on insert)?