feat(scheduler-core): implement periodic snapshot checkpointing (task 9.3)

Periodic checkpointing hooks into sched_record_write_events(): once per
call, when record_snapshot_interval > 0 and record_event_count crosses a
multiple of it, writes a fresh SnapshotEntry via the same
write_snapshot_entry() helper sched_record_start() already uses (made
non-static, zero duplication). Safe from the session_active precondition
because this call site is only ever reached from
xce_sched_driver_translate_pending_events(), which always runs strictly
between sessions.

Confirmed the write-failure error-handling half (AC 10) was already
complete from task 9.2's sched_record_abort_on_error() -- added the
missing end-to-end test using a genuine closed-fd write failure rather
than a mocked return code, proving the driver keeps processing sessions
afterward.

25/25 scheduler suite, clang-format clean. Two non-blocking follow-ups
logged in tasks.md: --record-snapshot-interval has no CLI wiring yet
(AC 11's own struct-field mechanism is fully tested, but nothing sets it
in production), and test_record_lifecycle.c has grown past this suite's
prior size precedent with a natural future split point identified.

src/scheduler/include/recording.h

@@ -211,6 +211,20 @@ extern int sched_record_stop(xce_scheduler_t* sched);
  * marker -- the file is presumably broken already) and a negative errno is
  * returned; the caller (driver.c) does not need to react further -- normal
  * scheduling continues either way (Req 5 AC 10, "Error handling").
+ *
+ * Periodic checkpoint (Req 5 AC 11, task 9.3): after the whole batch's
+ * events are written, if `sched->record_snapshot_interval > 0` and the
+ * (cumulative, since recording started) `sched->record_event_count` has
+ * just landed exactly on a multiple of it, a fresh `SnapshotEntry` message
+ * is appended (via recording.c's shared write_snapshot_entry(), the SAME
+ * builder sched_record_start() uses for the initial one -- DRY, never
+ * duplicated). `record_snapshot_interval == 0` disables this entirely.
+ * Checked ONCE per call against the post-batch count, not once per
+ * multiple crossed within one large batch -- see recording_events.c's own
+ * comment on sched_record_write_events() for the full boundary-semantics
+ * rationale. A checkpoint write failure disables recording via
+ * sched_record_abort_on_error(), the exact same path as any other
+ * recording write failure -- never special-cased.
  */
 extern int sched_record_write_events(xce_scheduler_t*  sched,
                                      xce_core_event_t* events, int n);

src/scheduler/include/scheduler.h

@@ -145,8 +145,11 @@ typedef struct {
      * by task 9.3's periodic-checkpoint trigger; incremented by
      * recording.c's event-batch writer, task 9.2). */
     uint64_t record_event_count;
-    /* N events between periodic snapshot checkpoints (0 = disabled).
-     * Reserved for task 9.3 -- inert (never read) as of task 9.2. */
+    /* N events between periodic snapshot checkpoints (0 = disabled). Read
+     * by recording_events.c's sched_record_write_events() (task 9.3):
+     * every time cumulative `record_event_count` lands exactly on a
+     * multiple of this value, a fresh SnapshotEntry is appended to the
+     * record file (Req 5 AC 11). */
     uint64_t record_snapshot_interval;
     /* logical time (xce_core_now()) recording started; 0 = not recording. */
     uint64_t record_start_ts;