feat(demo): refuse an event step at save with demoRefuses (MODULE_API 1.19.0)

DEMO_MODE.md §3.4 refuses a denied console command when the event is
saved and when it runs. Saving is core's route, and core never asked a
module about a step's params, so the save-time half had no seam (DM18).

An event action may now declare demoRefuses(params), returning a
sentence or null. With DEMO_MODE on, create, save and publish ask it
for every step; the first sentence refuses the write 403 DEMO_LOCKED
with that sentence as the message (and in errors). A hook that throws
refuses too. Off the demo it is validated and never called, and the
catalog strips it with the other callables.

The events controller passes code and message through on create,
update and publish, so the client's one DEMO_LOCKED toast fires.

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

client/src/modules/version.js

@@ -11,6 +11,9 @@
 // that the two files can drift, so a test asserts they agree
 // (client/test/moduleRegistry.test.js) rather than trusting a bump to remember
 // both.
+// 1.19.0 — an event action may declare `demoRefuses(params)` (DEMO_MODE.md §3.4,
+// DM18): the demo refuses a step at save. Server-side only; the refusal reaches
+// the browser as an ordinary DEMO_LOCKED answer. This file bumps for the reason at the top.
 // 1.18.0 — the public demo (DEMO_MODE.md §3.2): `demoLocks` in module.json,
 // `ctx.demoMode`, `api.onDemoSeed`. Server-side; the client half is core's own
 // banner and refusal toast, which an installed module's requests reach through
@@ -102,4 +105,4 @@
 // but the two halves state ONE version: a module declares a single coreApi range
 // and is served one chunk, so a client that claimed 1.0.0 while the server
 // answered 1.1.0 would be two answers to one question.
-export const MODULE_API_VERSION = '1.18.0'
+export const MODULE_API_VERSION = '1.19.0'