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/eventRunLog.db.js

@@ -0,0 +1,67 @@
+// ── event_run_log — SQL only ───────────────────────────────────────────────
+//
+// EVENTS.md § Observability. "Why didn't phase 3 start?" must be a query, and
+// `activity_log.detail` is TEXT and unqueryable, which is why this table exists
+// beside the audit log rather than instead of it. Both are written: the audit of
+// WHO published WHAT goes to `activity_log`, the diagnosis goes here.
+//
+// **`kind` is a closed set enforced here rather than an ENUM in the DDL.** The
+// set grows with almost every later phase — conditions in Phase 5, cap draws in
+// Phase 6, ledger movements in Phase 8 — and an ENUM change is a table alter
+// this project has no migration system for. A constant in a file is the same
+// guarantee with a cheaper hinge.
+
+const log = require('../../utils/logger')('events')
+const { query } = require('../../utils/db')
+const { parseJson } = require('./eventJson')
+
+// Phase 1's kinds. Later phases append; nothing here is ever renamed, because a
+// stored row would then name a kind no reader knows.
+const KINDS = [
+  'run.created',      // an occurrence was materialised
+  'run.status',       // a status transition, with from/to
+  'phase.entered',    // a phase's steps were materialised
+  'step.status',      // a step transition, with the module's answer
+  'note',             // a human action taken from the admin surface
+]
+
+const hydrate = (row) => row && { ...row, detail: parseJson(row.detail, null) }
+
+const listForRun = async (runId, { limit = 500 } = {}) => {
+  const n = Math.min(Math.max(Number(limit) || 500, 1), 2000)
+  return (
+    await query(`SELECT * FROM event_run_log WHERE run_id = ? ORDER BY at DESC, id DESC LIMIT ${n}`, [
+      runId,
+    ])
+  ).map(hydrate)
+}
+
+/**
+ * Write one line. **Never throws.**
+ *
+ * The diagnostic log is what an operator reads when something has already gone
+ * wrong, so a failure to write it must not become a second failure on top of the
+ * first — a runner that aborted a run because it could not record why would be
+ * the worst possible reading of "observability". The same posture
+ * `uoLinkClient.js` takes: answer, do not throw.
+ */
+async function write({ runId, stepId = null, kind, phase = null, detail = null }) {
+  if (!KINDS.includes(kind)) {
+    // A programming error, not an operational one, and it is louder than a
+    // silent drop for exactly that reason.
+    log.warn('event run log: unknown kind', { kind, runId })
+    return false
+  }
+  try {
+    await query(
+      'INSERT INTO event_run_log (run_id, step_id, kind, phase, detail) VALUES (?, ?, ?, ?, ?)',
+      [runId, stepId, kind, phase, detail === null ? null : JSON.stringify(detail)],
+    )
+    return true
+  } catch (err) {
+    log.error('event run log write failed', { runId, kind, message: err.message })
+    return false
+  }
+}
+
+module.exports = { KINDS, listForRun, write }