[events] event tagging and reporting

apps/api/migrations/0010_event_tag.sql

@@ -0,0 +1,25 @@
+-- Player-event tags: the categories an event is filed under (`workshops`, `meetup`, …),
+-- one row per tag per event. Owned by the `api` worker; generated from src/events-db.ts
+-- (SCHEMA_DDL) — keep in sync.
+--
+-- A separate table rather than a field on the event blob, for a reason that isn't
+-- storage taste: the stored blob IS the event DTO every read serves verbatim, and the
+-- event reads do NOT carry tags — they surface only behind
+-- `GET /api/playerevents/v1/{id}?includeDetails=True`. Putting them in the blob would
+-- leak a `Tags` key into every other read.
+--
+-- `tag` is stored lowercased and is the search key: `?query=%23workshops` (a `#`-prefixed
+-- term) filters on this table, while a bare term still matches the name/description.
+-- `type` is the client's tag-category int, echoed back as sent — its enum isn't reversed
+-- yet, and nothing here interprets it.
+--
+-- The primary key is (event_id, tag): an event can't carry the same tag twice, and a tag
+-- edit REPLACES the event's set rather than accumulating.
+
+CREATE TABLE IF NOT EXISTS event_tag (
+  event_id INTEGER NOT NULL,
+  tag TEXT NOT NULL,
+  type INTEGER NOT NULL DEFAULT 0,
+  PRIMARY KEY (event_id, tag)
+  );
+CREATE INDEX IF NOT EXISTS idx_event_tag_tag ON event_tag (tag);

apps/api/migrations/0011_report_event.sql

@@ -0,0 +1,20 @@
+-- Reporting a player EVENT (`POST /api/playerevents/v1/report`) reuses the report
+-- table rather than getting one of its own: it is the same submission with the same
+-- fields (category, free-text details, the reporter from the token) and the same
+-- moderation life — a moderator acting on it sets `banned` on the row exactly as they
+-- would for a player report. Generated from src/reports-db.ts (SCHEMA_DDL) — keep in
+-- sync.
+--
+-- `event_id` names the reported event; NULL on every ordinary player report, which is
+-- what tells the two kinds apart. The row's other columns are still filled in from the
+-- event: `reported_player_id` is its CREATOR (the person a moderator would act
+-- against — the column is NOT NULL, and "who is answerable for this event" is the only
+-- honest answer), and `room_id` the room it runs in, read from the event table so the
+-- client doesn't have to send either.
+--
+-- Partial index: event reports are a small minority of rows, so indexing only the ones
+-- that name an event keeps "reports against this event" off a full scan without paying
+-- for the NULLs.
+
+ALTER TABLE report ADD COLUMN event_id INTEGER;
+CREATE INDEX IF NOT EXISTS idx_report_event ON report (event_id) WHERE event_id IS NOT NULL;