feat(events): the public calendar, event pages and participation history (Phase 14a)

The anonymous surface an event was always for: GET /public/events,
/public/events/:slug and /public/events/series/:slug, plus
GET /player/events/history, and the four screens over them.

Four org-lead decisions taken up front: split Phase 14 into 14a (website)
and 14b (the app); add a `listed` flag rather than letting `state` mean both
schedulable and announced; put the `events` capability string in the version
block rather than publishing core as a pseudo-module; and drop "venue" from
the spec rather than adding a field nothing had ever built.

`listed` is announcement, not permission. Publishing is what makes a
definition runnable, so without a separate flag a surprise event would have
to be advertised in order to be allowed to happen. It is a column, a switch
in Phase 13's editor, and three SQL predicates -- never a filter applied
after a read, which works exactly as well until the first caller that forgets.

The public shapes are a projection, and the projection is the security
boundary: nothing is spread, so a column added to event_runs next year does
not ride out through it. The spec, health, cleanup, claims, errors and
member_key are all absent by construction.

The six public event triggers gained `eventUrl` (version 1 -> 2), carrying
?run= because the page lives at the definition's slug while every trigger is
about one occurrence. notify.event-started gained the button, at seedVersion 2.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

server/db/schema.sql

@@ -2598,6 +2598,25 @@ CREATE TABLE IF NOT EXISTS event_run_resources (
 ALTER TABLE event_versions ADD COLUMN IF NOT EXISTS verified_at DATETIME NULL;
 ALTER TABLE event_versions ADD COLUMN IF NOT EXISTS verified_by INT NULL;
 
+-- Whether this definition appears on the PUBLIC calendar (Phase 14a).
+--
+-- **Not a second answer to the question `state` answers**, which is the trap the
+-- `findSchedulable` comment in eventDefinitions.db.js warns about: `state` says
+-- whether an event is SCHEDULABLE, and this says whether it is ANNOUNCED. The
+-- two came apart the moment there was a public surface at all, because
+-- publishing is what makes a definition runnable -- so without this column a
+-- surprise invasion would have to be advertised a fortnight in advance in order
+-- to be allowed to happen.
+--
+-- Default 1, so every definition that exists keeps the behaviour it had while
+-- the only reader was staff, and unlisting is the deliberate act.
+--
+-- It hides the definition, its runs and its projections from the public
+-- surfaces and from a participant's own history. It hides nothing from staff:
+-- the admin calendar is the operational view, and an event nobody outside can
+-- see is still an event the team is running.
+ALTER TABLE event_definitions ADD COLUMN IF NOT EXISTS listed TINYINT(1) NOT NULL DEFAULT 1;
+
 -- ── Integrations: participants, results and the run's announcements
 --    (EVENTS.md §D/§J — Phase 10) ─────────────────────────────────────────────