Draft events still show RSVP options, and RSVPing returns a misleading "event is cancelled" error

## What happens Opening a **draft** event (one that hasn't been published yet) on its public page still shows the RSVP options as if the event were live. If you click an RSVP button, the backend rejects the request and returns the message **"event is cancelled"** — but the event isn't cancelled, it's a draft. Two bugs stacked: 1. **UI**: draft events shouldn't surface the RSVP UI to non-hosts at all (and probably shouldn't be reachable by URL to non-hosts in the first place). 2. **Error wording**: when an RSVP is rejected because of event status, the message says "cancelled" regardless of which non-published status the event is actually in. A user attempting to RSVP to a draft is told "this event is cancelled" — confusing and misleading. ## How to reproduce 1. As an event host, create a new event but **don't publish it** — leave it in `draft` status. 2. Open the event detail page (or share the link with another logged-in user). 3. Observe: the RSVP buttons (Going / Maybe / Not going, or whatever the live UI shows) are visible. 4. Click any RSVP option. 5. Observe: error toast / response says **"event is cancelled"**. ## Expected - A draft event's public/detail page should **not show RSVP controls** to anyone except the host(s). For non-hosts, the page should either be hidden entirely (404) or render in a host-preview mode that clearly states "This event is a draft and isn't visible to attendees yet." - If the backend ever does reject an RSVP for a non-live event, the **error message must reflect the actual status** — `draft` / `cancelled` / `completed` are different states and should produce different messages. ## Likely root cause (technical) - **Frontend**: the event detail page probably renders the RSVP block whenever `event.id` is set, without checking `event.status`. The check should be something like `event.status === 'published'` (or `=== EventStatus.Published`). - **Backend**: the RSVP endpoint likely rejects any non-`published` event with a hardcoded "event is cancelled" message instead of branching on the actual status. A `match event.status` block (or equivalent) returning per-status error codes — `EVENT_NOT_PUBLISHED`, `EVENT_CANCELLED`, `EVENT_COMPLETED` — would let the frontend translate properly via i18n. ## Impact - Confusing for hosts previewing their drafts (sees public-style UI). - Confusing / scary for any non-host who somehow lands on a draft URL — they get told the event is cancelled when it never existed publicly. - The wrong-error-message half also affects any future genuine cancellation flow — debugging "why does it say cancelled?" is harder when both states share a message. ## Found by Manual testing