feat(events): schema, CRUD and the core action registry (Phase 1)

EVENTS_PLAN.md Phase 1. Six of the nine core tables — the ones that do not
depend on the module contract — plus definitions CRUD, publish, archive, and
the action registry with core as its first registrant.

**Nothing dispatches.** There is no runner until Phase 2, so a run row is
created and stays `scheduled`. That is this phase's correct answer and the
surface renders it verbatim rather than hiding it.

Schema (`db/schema.sql`, append-only):
  event_series, event_definitions, event_versions, event_runs,
  event_run_steps, event_run_log. The four that need a writer —
  event_action_settings, event_run_budget, event_run_resources,
  event_run_participants — arrive with the phases that give them one.

Registry (`modules/registries.js` + `config/coreEventActions.js`):
  registerEventActions staging and commit, with its own id namespace, the
  closed risk and reversibility sets, revert() required iff and only iff
  reversible: 'ledger', a bounded budgetMs and a param shape whose every
  entry needs a type and an example. perform/revert/cost are stripped from
  everything the catalog serves. Core declares core.announce, core.wait and
  core.cue through the same staging area a module will use.

  It is reachable ONLY by registerCore(): loader.js builds its own api facade
  and has no method that delegates here, so no module can call it and
  MODULE_API_VERSION is untouched. Phase 7 adds the facade and the bump.

Surface (13 routes under /api/v1/admin/events):
  Reads staff-wide; publish, archive and run creation admin-only from this
  phase per EVENTS.md §N2, even though the switchboard they will consult does
  not exist yet — a button that is admin-only later and open now is a gate
  nobody notices was missing. The live run controls and `verify` are absent
  rather than stubbed, because nothing is in flight yet.

Four things the build settled, all recorded in docs:
  - event_definitions gained a `spec` column. A draft's working copy cannot
    be an event_versions row: that table is immutable and a run pins one.
  - The spec validator must accept its own output. It added `actionVersion`
    and `dormant` and then refused them as unknown keys, which would have made
    the second save of any definition — and publish's re-validation —
    impossible. A test caught it; both are now accepted and recomputed.
  - A param's `example` is required, optional params included, matching
    registerEventTriggers. It is the authoring form's placeholder.
  - Two routes the §API-surface table did not name: GET /admin/events/:id and
    GET /admin/events/series.

Core's three perform() bodies answer { ok: false, retry: false } rather than
{ ok: true }: `ok: true` on an action that did nothing is a recorded world
change that did not occur, which is the exact mistake §F's failure default
exists to prevent.

`conditions.checkLiteral` is exported and reused for step-param type checking
— one switch over the six types, so "is this a datetime" has one answer.

Verified: 44 new tests, whole server suite, `npm run check:modules`, routes
manifest and swagger regenerated (the manifest diff is +13 routes, zero moved).

Docs: RunicGateway/docs#209

Co-Authored-By: Claude <noreply@anthropic.com>

server/src/model/events/eventRunSteps.db.js

@@ -0,0 +1,95 @@
+// ── event_run_steps — SQL only ─────────────────────────────────────────────
+//
+// EVENTS.md §D and §E. Phase 1 materialises a run's steps and reads them back
+// for the run console. **Draining them is Phase 2's**: the CAS claim, the lease,
+// the attempt counter and the classification of a module's answer are the
+// runner, and none of them is stubbed here.
+//
+// The one runtime property Phase 1 does have to get right is the idempotency key
+// (§E). Core mints it ONCE, at materialisation, and it does NOT vary by attempt —
+// a retry re-sends the same key so the game side can recognise the repeat. That
+// makes it a property of the INSERT below rather than of the dispatch, which is
+// the only reason it can be stable at all.
+
+const crypto = require('crypto')
+
+const { query } = require('../../utils/db')
+const { parseJson } = require('./eventJson')
+
+const hydrate = (row) => row && { ...row, params: parseJson(row.params, {}) }
+
+/**
+ * `sha256(runId | stepId)`, truncated to 40 hex — the shape `shardEvents.dedupeKey`
+ * already uses, so the two dedupe keys on this codebase read alike.
+ *
+ * The step id is not known until the row exists, so materialisation inserts with
+ * a provisional key and stamps the real one immediately afterwards. That is one
+ * extra statement per step and it buys the property the whole retry story rests
+ * on: the key is a function of identity, never of attempt or of clock.
+ */
+const idempotencyKey = (runId, stepId) =>
+  crypto.createHash('sha256').update(`${runId}|${stepId}`).digest('hex').slice(0, 40)
+
+const listForRun = async (runId) =>
+  (
+    await query(
+      'SELECT * FROM event_run_steps WHERE run_id = ? ORDER BY phase, seq, id',
+      [runId],
+    )
+  ).map(hydrate)
+
+const getById = async (id) => {
+  const [row] = await query('SELECT * FROM event_run_steps WHERE id = ?', [id])
+  return hydrate(row)
+}
+
+/**
+ * Materialise one phase's steps.
+ *
+ * `INSERT IGNORE` against `UNIQUE (run_id, phase, seq)`, so a tick that overran
+ * into the next one cannot double-materialise a phase — the same argument the
+ * occurrence key makes one table up, at the other end of the run.
+ *
+ * Returns the rows as they now stand, created or pre-existing, so a caller that
+ * lost the race still gets the step ids.
+ */
+const materialisePhase = async (runId, phase, steps) => {
+  for (let i = 0; i < steps.length; i++) {
+    const step = steps[i]
+    const result = await query(
+      `INSERT IGNORE INTO event_run_steps
+         (run_id, phase, seq, action_id, params, action_version, on_failure, idempotency_key)
+       VALUES (?, ?, ?, ?, ?, ?, ?, '')`,
+      [
+        runId,
+        phase,
+        i,
+        step.actionId,
+        JSON.stringify(step.params || {}),
+        step.actionVersion || 1,
+        step.onFailure || 'pause',
+      ],
+    )
+    if (Number(result?.affectedRows || 0) === 1) {
+      // Stamped in a second statement because the key is a function of the row's
+      // own id. Scoped by the empty key so a re-run of this loop over an existing
+      // phase can never overwrite a key a dispatch has already sent.
+      await query(
+        "UPDATE event_run_steps SET idempotency_key = ? WHERE id = ? AND idempotency_key = ''",
+        [idempotencyKey(runId, result.insertId), result.insertId],
+      )
+    }
+  }
+  return listForRun(runId)
+}
+
+/** The run console's summary line: how many steps sit in each status. */
+const statusCounts = async (runId) => {
+  const rows = await query(
+    'SELECT status, COUNT(*) AS n FROM event_run_steps WHERE run_id = ? GROUP BY status',
+    [runId],
+  )
+  return Object.fromEntries(rows.map((r) => [r.status, Number(r.n)]))
+}
+
+module.exports = { listForRun, getById, materialisePhase, statusCounts, idempotencyKey }