feat(events): schedule, recurrence and the calendar (Phase 4)

The four closed recurrence shapes computed in the definition's own IANA zone,
a fourteen-day materialisation horizon with projections beyond it, series as a
managed thing, and the admin calendar that replaces the plugin this feature
exists to replace. An event now happens on its own.

No schema change: Phase 1 built every column this needed.

- events/recurrence.js is the ONE place an occurrence is computed, so the
  runner's expansion and the calendar's forecast cannot disagree. No date
  library added — Node ships the tzdata one would vendor, behind Intl.
- The runner's materialise leg is now two halves: expand, then sweep. The
  window starts at `now - grace`, so an occurrence nobody could have seen is
  never invented retroactively; the horizon is what makes the missed sweep
  mean anything for a recurrence.
- Publishing is the schedule switch and archiving turns it off, and publishing
  re-pins every occurrence that has not started.
- A projection is never drawn over an instant a run occupies, so a cancelled
  occurrence does not reappear as a forecast.

54 new tests, incl. the DST fixture set the plan asked for and three new
statements proved against a real MariaDB. Suite 1768/1711/56 skipped/1 fail
(pre-existing CRLF). Walked end to end on the local review stack.

Docs: RunicGateway/docs#PENDING

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

server/src/model/events/eventRuns.model.js

@@ -50,9 +50,21 @@ function renderConcurrencyKey(template, params) {
  *
  * `scheduledFor` defaults to now — "start now" is an occurrence whose instant is
  * the present, not a separate concept, which is what keeps the runner's one
- * materialise/advance path honest when Phase 4 adds recurrence on top.
+ * materialise/advance path honest now that Phase 4 has put recurrence on top.
+ *
+ * **Phase 4's expansion calls this, rather than a second insert path beside it.**
+ * That is deliberate: every check here — the definition is still `ready`, the
+ * version still has phases, the concurrency key renders, the first phase's steps
+ * are materialised with their idempotency keys — is one a scheduled occurrence
+ * needs at least as much as a hand-started one, because there is nobody watching
+ * when it happens. The `INSERT IGNORE` answering `created: false` is what makes
+ * it safe to call on every tick for every occurrence inside the horizon.
  */
-async function create(definitionId, { scope = '', scheduledFor = null, rehearsal = false, params = null } = {}, userId) {
+async function create(
+  definitionId,
+  { scope = '', scheduledFor = null, rehearsal = false, params = null, source = 'manual' } = {},
+  userId,
+) {
   const definition = await definitionsDb.getById(definitionId)
   if (!definition) return { ok: false, status: 404, errors: ['no such event definition'] }
   if (definition.state !== 'ready') {
@@ -107,6 +119,11 @@ async function create(definitionId, { scope = '', scheduledFor = null, rehearsal
       version: version.version,
       scope: scopeValue,
       rehearsal: Boolean(rehearsal),
+      // 'manual' is an admin pressing start; 'schedule' is the runner expanding
+      // a recurrence (Phase 4). Both produce the same row, and the log is the
+      // only place the difference is recorded — `started_by` is NULL for both a
+      // scheduled occurrence and one started by a since-deleted account.
+      source,
       by: userId,
     },
   })